Menu
▾
▴
linuxconsole-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(235) |
Apr
(30) |
May
(32) |
Jun
(86) |
Jul
(81) |
Aug
(108) |
Sep
(27) |
Oct
(22) |
Nov
(34) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(78) |
Feb
(10) |
Mar
(81) |
Apr
(27) |
May
(13) |
Jun
(105) |
Jul
(78) |
Aug
(52) |
Sep
(59) |
Oct
(90) |
Nov
(127) |
Dec
(49) |
| 2002 |
Jan
(102) |
Feb
(72) |
Mar
(54) |
Apr
(98) |
May
(25) |
Jun
(23) |
Jul
(123) |
Aug
(14) |
Sep
(52) |
Oct
(65) |
Nov
(48) |
Dec
(48) |
| 2003 |
Jan
(22) |
Feb
(25) |
Mar
(29) |
Apr
(12) |
May
(16) |
Jun
(11) |
Jul
(20) |
Aug
(20) |
Sep
(43) |
Oct
(84) |
Nov
(98) |
Dec
(56) |
| 2004 |
Jan
(28) |
Feb
(39) |
Mar
(41) |
Apr
(28) |
May
(88) |
Jun
(17) |
Jul
(43) |
Aug
(57) |
Sep
(54) |
Oct
(42) |
Nov
(32) |
Dec
(58) |
| 2005 |
Jan
(80) |
Feb
(31) |
Mar
(65) |
Apr
(41) |
May
(20) |
Jun
(34) |
Jul
(62) |
Aug
(73) |
Sep
(81) |
Oct
(48) |
Nov
(57) |
Dec
(57) |
| 2006 |
Jan
(63) |
Feb
(24) |
Mar
(18) |
Apr
(9) |
May
(22) |
Jun
(29) |
Jul
(47) |
Aug
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: <jsi...@ac...> - 2000-03-23 15:23:05
|
> Must we have [linuxconsole-dev] in every subject line? I request > that it be removed. There are plenty of other header fields to > sort messages into individual folders with, and this issue is > something that comes up on many lists from time to time. > > In the end, there is never any useful technical reason to include > the listname in every message's subject line. > > Use: > > Sender: lin...@li... > > as a filter rule, and be done with it. Please change this. I just fixed it :) |
|
From: <jsi...@ac...> - 2000-03-23 15:17:55
|
test |
|
From: Dominik K. <dom...@un...> - 2000-03-23 08:31:11
|
On Thu, Mar 23, 2000 at 02:18:12AM -0500, Mike A. Harris wrote: > Must we have [linuxconsole-dev] in every subject line? I request > that it be removed. There are plenty of other header fields to Yes, get rid of it. Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Mike A. H. <mh...@me...> - 2000-03-23 07:23:08
|
Must we have [linuxconsole-dev] in every subject line? I request
that it be removed. There are plenty of other header fields to
sort messages into individual folders with, and this issue is
something that comes up on many lists from time to time.
In the end, there is never any useful technical reason to include
the listname in every message's subject line.
Use:
Sender: lin...@li...
as a filter rule, and be done with it. Please change this.
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
I've overclocked my keyboard interface. It's quite messy dipping my
hands into the mineral oil, but *MAN* is my keyboard ever fast now!
- Anonymous Coward
|
|
From: James S. <jsi...@ac...> - 2000-03-23 04:25:56
|
> > Yuck. I want to have all my video cards and keybaords boot up as fully > > functional consoles. Their are problems with con2fb. The biggest is no > > locking on SMP machines. With seperate VT pools on each display then > > life will be much easier. > > You misunderstood me. I was referring to the console that gets kernel > printk() output. This really doesn't have anything to do with VTs. Oops. It makes sense to do it this way. Any opinions here ? "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Brad D. <Br...@NE...> - 2000-03-23 03:47:34
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > On Wed, 22 Mar 2000, Brad Douglas wrote: > > > > -----Original Message----- > > > From: James Simmons [mailto:jsi...@ac...] > > > > > > Not really. What about the ability to send kernel output to the printer. > > > Yes 2.3.X does have such ability. What about a system with a serial > > > console and regular VT. Yes some PC motherboards are now starting > > > to support serial consoles. The ia64 machines have both I believe. Which > > > one do we send it to then. > > > > FYI, I briefly looked into the issue of multiple kernel "consoles" in > > regard to multi-head. It does not appear to be an issue... There can > > only be one kernel console -- And it can be easily moved from device to > > device in userland (a program already exists). > > Yuck. I want to have all my video cards and keybaords boot up as fully > functional consoles. Their are problems with con2fb. The biggest is no > locking on SMP machines. With seperate VT pools on each display then > life will be much easier. You misunderstood me. I was referring to the console that gets kernel printk() output. This really doesn't have anything to do with VTs. Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-03-23 03:43:35
|
On Wed, 22 Mar 2000, Brad Douglas wrote: > > -----Original Message----- > > From: James Simmons [mailto:jsi...@ac...] > > > > Not really. What about the ability to send kernel output to the printer. > > Yes 2.3.X does have such ability. What about a system with a serial > > console and regular VT. Yes some PC motherboards are now starting > > to support serial consoles. The ia64 machines have both I believe. Which > > one do we send it to then. > > FYI, I briefly looked into the issue of multiple kernel "consoles" in > regard to multi-head. It does not appear to be an issue... There can > only be one kernel console -- And it can be easily moved from device to > device in userland (a program already exists). Yuck. I want to have all my video cards and keybaords boot up as fully functional consoles. Their are problems with con2fb. The biggest is no locking on SMP machines. With seperate VT pools on each display then life will be much easier. |
|
From: Brad D. <Br...@NE...> - 2000-03-23 03:15:14
|
> -----Original Message----- > From: James Simmons [mailto:jsi...@ac...] > > Not really. What about the ability to send kernel output to the printer. > Yes 2.3.X does have such ability. What about a system with a serial > console and regular VT. Yes some PC motherboards are now starting > to support serial consoles. The ia64 machines have both I believe. Which > one do we send it to then. FYI, I briefly looked into the issue of multiple kernel "consoles" in regard to multi-head. It does not appear to be an issue... There can only be one kernel console -- And it can be easily moved from device to device in userland (a program already exists). Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: Justin C. <jp...@do...> - 2000-03-22 20:43:59
|
> > > > Take > > > > /dev/fb. You wouldn't want to be on a console and then all the sudden > >a X > > > > session starts because someone ran X on anther station requestion that > > > > head you are on. I really like to see the X server some day just using > > > > /dev/input and /dev/fb instead of any VTs like its does now. > > how close does the XGGI "server" come to this? It runs on any target you like. You can run it in a window under X if you like. Justin |
|
From: Firstname L. <ms...@ho...> - 2000-03-22 20:14:20
|
= > > That is basically how my approach works internally to implement > > consoles. > > The video hardware drivers, input hardware drivers etc. only care about > > mapping a virtual representation (devices) to the actual hardware. > >Yeap. That's the direction fbdev is heading in and Vojtech is doing the >same for the input suite. > > > > Take > > > /dev/fb. You wouldn't want to be on a console and then all the sudden >a X > > > session starts because someone ran X on anther station requestion that > > > head you are on. I really like to see the X server some day just using > > > /dev/input and /dev/fb instead of any VTs like its does now. how close does the XGGI "server" come to this? Corey ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com |
|
From: Firstname L. <ms...@ho...> - 2000-03-22 20:07:00
|
> > > also, another possiblity would be to make solid api's for the fb, and > > > inputX, then create whatever console code you wanted in userspace, > > > bypassing any of linus's kernel decisions. > > > > Personally I think this is the best approach for multihead aware >programs. > >A view I share. I haven't looked into it, but i seem to remember some stuff like user-space drivers... is it possible to create a user-space device? if so, you could simulate a device, for non-multihead aware programs. Corey (note i am no longer subscribed to the list) ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com |
|
From: James A S. <jsi...@ac...> - 2000-03-21 16:39:54
|
On Sun, 19 Mar 2000, Dominik Kubla wrote: > Just as i expected: can't check-in through a firewall which blocks ssh. > So i'll have to do it tomorrow when i will have my laptop in front of > that beastie... Until then you can grap the patch against 2.3.99-pre1 > from my web pages: > > http://www-klinik.uni-mainz.de/staff/kubla/Linux/ I'm going to be applying it tonight to the current tree we have. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: James A S. <jsi...@ac...> - 2000-03-21 16:05:11
|
> > I was playing with it but ended up with a few questions. I noticed the > > drivers in 2.3.99 in the usb directory where the same files in > > drivers/input in your input-0.4.4 patch but some where more up to date. I > > did know how or which ones to move over without breaking things in usb. > > All that's needed is to move the CONFIG_INPUT_* options from the USB > Config.in and Makefile to the one in the drivers/input directory. All > should work, the USB stuff doesn't link with those. All files that are > now in drivers/input can be deleted from drivers/usb. Okay. I will do this tonight. I will use the stuff in 2.3.99 to move it over. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: Vojtech P. <vo...@su...> - 2000-03-20 15:14:53
|
On Mon, Mar 20, 2000 at 10:01:27AM -0500, James A Simmons wrote: > > On Sun, 19 Mar 2000, Vojtech Pavlik wrote: > > > Hi! > > > > I've added my input drivers to the CVS. No kernel bindings at the > > moment, those have to be pulled out of the input patch. As far as I > > know, someone has been working on porting the patch to 2.3-latest. > > > > Any progress or should I do it myself? > > I was playing with it but ended up with a few questions. I noticed the > drivers in 2.3.99 in the usb directory where the same files in > drivers/input in your input-0.4.4 patch but some where more up to date. I > did know how or which ones to move over without breaking things in usb. All that's needed is to move the CONFIG_INPUT_* options from the USB Config.in and Makefile to the one in the drivers/input directory. All should work, the USB stuff doesn't link with those. All files that are now in drivers/input can be deleted from drivers/usb. -- Vojtech Pavlik SuSE Labs |
|
From: James A S. <jsi...@ac...> - 2000-03-20 15:06:44
|
On Sun, 19 Mar 2000, Vojtech Pavlik wrote: > Hi! > > I've added my input drivers to the CVS. No kernel bindings at the > moment, those have to be pulled out of the input patch. As far as I > know, someone has been working on porting the patch to 2.3-latest. > > Any progress or should I do it myself? I was playing with it but ended up with a few questions. I noticed the drivers in 2.3.99 in the usb directory where the same files in drivers/input in your input-0.4.4 patch but some where more up to date. I did know how or which ones to move over without breaking things in usb. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: James A S. <jsi...@ac...> - 2000-03-20 15:04:13
|
On Sun, 19 Mar 2000, Dominik Kubla wrote: > On Sun, Mar 19, 2000 at 10:17:47AM -0500, James Simmons wrote: > > > > I just commited some fbcon changes. These chanegs break any current > > How about character attribute handling? Right now the vt emulation handles > this stuff. That's plain wrong. It should just tell the screen driver > to print character c with bold,underline,blink and green color enabled. > If the backend can't handle that, it should substitute... (Also it would > of course be a mistake of the VTE to issue a color request on a monochrome > display...) Of course. It can do this. If you look at consw their is a function pointer a driver can have for consoel attributes. Right now I'm working on the accel wrapper for fbcon. It will support this stuff. First I got to get the 3Dfx fbdev driver to boot and work. > PPS. I think we need to import the whole kernel tree into CVS, at least > for ruby: i am now touching files in include/linux, drivers/char and > will add stuff to Documentation soon. So am I. The whole tree. Thats alot to keep in sync with 2.4.X. We can of course. Right now the kernel (2.3.99-pre2) is still rapidly chaning so it's not a good idea just yet. > There is BTW no need to check out > the whole tree: you can tell cvs to make a diff in the repository and > only transfer the diff-file. Makes it easy for us to automatically create > snapshot patches too. What do you think about this? Thats really nice :) I'm not a CVS guru so how do you go about doing that. "Look its a text editor, no its a OS, no its Emacs" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net |
|
From: Steffen S. <s.s...@ph...> - 2000-03-20 09:14:01
|
Firstname Lastname wrote: > > > > > > Do you have access to a old monochrome display adapter (MDA)? In that > > > case you might want to give KGI a try and test it yourself. > > > >No :( > > > > Last time i checked the monichrome driver in kgicon failed to compile (cause > it wasn't being maintained). I assume that KGI has a similar issue. give > it a try. Not as far as I could test it. I have had an monochrome and VGA card plus two PS/2 keyboards happily booting as a true multihead machine with KGI-0.9. Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... |
|
From: Dominik K. <dom...@un...> - 2000-03-19 22:21:33
|
Just as i expected: can't check-in through a firewall which blocks ssh. So i'll have to do it tomorrow when i will have my laptop in front of that beastie... Until then you can grap the patch against 2.3.99-pre1 from my web pages: http://www-klinik.uni-mainz.de/staff/kubla/Linux/ New stuff: * Recognizing all private/experimental parameter flags as per ISO-6429. * All C0/C1 control functions are handled (C1 handling depends on S8C1T setting). Misuse of codes by existing code is depending on the absence of a VT_STRICT_ISO define (which is undefined by default, since the conflicts are not hurting the current state of the implementation) * 8-bit controls work (we are ahead of *BSD here!) * Locator report defaults to "no locator" * First try at G2/G3 charsets and single shifts. Not functional! * Replaced Eric's VTE_VERSION ifdef's with proper CONFIG_VT_EXTENDED and added them to Config.in. * Changed MAINTAINERS and CREDITS files. * Secondary [vt200+] and tertiary [vt400+] DA work. * DECSTR (soft terminal reset) implemented as RIS. * Added some more private modes. Not all are functional or even useful. More an attempt a preventing misuse... DECNKM (numeric keypad mode) does work so! * Fake DECMSR (Macro Space Report, vt400+) added: always reports 0 bytes free. * DECRQM/DECRPM (Request Mode/Report Mode) implemented. * DECSCL (Set operating level) implemented. Appears to work. First stab at isolating vt220+ features while in "level 1" (aka vt100 mode). Known Issues: * Wrap around problem with tabstops. (Maybe somebody can spot this, i couldn't until now and i have been looking for two days!) * Send/Receive Mode: we don't emulate local echo. (But since we report SRM as permanently reset, not much of a problem) * Charset mapping: broken (when looking at VT102+ compatibility), but then the original sources show the same behaviour. * Keyboard Action Mode: "implemented" but non-functional. How to tell the keyboard driver to _NOT_ process keystrokes for a certain VT? * Compilation with CONFIG_VT_EXTENDED undefined is not tested, possibly incomplete and does probably not work. (*GRIN*) * Configure.help entries for new config options missing. * Need to sort out differences between RIS and DECSTR. * Some control function codes are misused by DEC (prior to vt420) and/or Linux. No big deal at the moment. * Answerback message does not work. (WHY?) * Answerback message can not be changed. Missing stuff for full VT220 comptibility: * Charset mapping and anything related to it. * DECUDK (user-defined keys) * DECCOLM (80/132 switching) * DECSCLM (jump scroll/smooth scroll switching) * DECNCRM (national replacement charset as per ISO-646; 7-BIT!) * DECDLD (downloadable softfonts) * DECANM (vt52 emulation; YUK!) * Color palette handling a la vt241 * DECSCA/DECSEL/DECSED (character protection and selective erasing) * CRM (control representation mode) [really? or is this vt320/vt420?] * Locator support [optional] * True underline and blinking character attributes. BTW, just in case you are curious: my current kernel built (starting with #1 on Friday evening and sleeping 8 hrs each night) is #77... Dominik -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: Vojtech P. <vo...@su...> - 2000-03-19 19:23:04
|
Hi! I've added my input drivers to the CVS. No kernel bindings at the moment, those have to be pulled out of the input patch. As far as I know, someone has been working on porting the patch to 2.3-latest. Any progress or should I do it myself? -- Vojtech Pavlik SuSE Labs |
|
From: Dominik K. <dom...@un...> - 2000-03-19 19:14:33
|
On Sun, Mar 19, 2000 at 10:17:47AM -0500, James Simmons wrote: > > I just commited some fbcon changes. These chanegs break any current How about character attribute handling? Right now the vt emulation handles this stuff. That's plain wrong. It should just tell the screen driver to print character c with bold,underline,blink and green color enabled. If the backend can't handle that, it should substitute... (Also it would of course be a mistake of the VTE to issue a color request on a monochrome display...) Comments? Dominik PS. As you can see i am back from my short weekend vacation. Did a whole lot of work on ruby. CVS commit to come later tonight... (And i did introduce a bug i can't chase down... ARGH!) PPS. I think we need to import the whole kernel tree into CVS, at least for ruby: i am now touching files in include/linux, drivers/char and will add stuff to Documentation soon. There is BTW no need to check out the whole tree: you can tell cvs to make a diff in the repository and only transfer the diff-file. Makes it easy for us to automatically create snapshot patches too. What do you think about this? -- Networking Group, Hospital of Johannes Gutenberg-University Obere Zahlbacher Straße 69, 55101 Mainz, Germany Tel: +49 (0)6131 17-2482 FAX: +49 (0)6131 17-5521 |
|
From: James S. <jsi...@ac...> - 2000-03-19 15:12:04
|
I just commited some fbcon changes. These chanegs break any current fbdev driver so they have to be modified. I working on modifing the 3Dfx fbdev driver. fbcon.c and fbmem.c take advanatge of the fb_info fields. I moved blank from fb_info to fb_ops. I replaced fb_ops of set_cmap with set_colreg. I removed the con parameter to all fbops operations. I commited a vfb.c that reflects these changes. The 3Dfx driver isn't complete yet. The next step is to develope a unified cursor api and discuss using encode_var and decode_var in place of set_var. This will have to be discussed on the fbdev list. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: James S. <jsi...@ac...> - 2000-03-19 14:03:55
|
A problem reported with the linux console system. I'm working on something else so I can't focus on this problem. Anyone wants to take a stab at it. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U ---------- Forwarded message ---------- Date: Sun, 19 Mar 2000 00:21:41 +0000 (GMT) From: Russell King <rm...@ar...> To: lin...@vg... Subject: 2.3.99pre2-5 console problems Original message: > From: Russell King <rm...@ar...> > Subject: 2.3.99pre1 console and NFS problems? > To: lin...@vg... > Date: Thu, 16 Mar 2000 22:43:29 +0000 (GMT) > > I'm using fbcon, and with 2.3.99pre1 I see the following problems: > > 2. If I ssh to one of my other machines from 2.3.99pre1, and do a > vdir /usr/bin, then the local ssh process will hang in an interruptible > wait in write_chan (just where the schedule() call is at the bottom of > the loop. The same is true with 2.3.99pre2-5. It is hanging in the same place, and this problem is very very reproducable. All I need to do is to use ssh to log into a remote machine on a 10base link, and then a simple "vdir /usr/bin" stops ssh in it's tracks. One recovery method from this situation is to login as root and strace the ssh process. That kicks it forward by a couple of page-fulls, then you have to stop stracing it and re-strace it until it reaches the end of the list. The reason it seems to be happening is that ssh is trying to write to the console using large blocks, which is causing the console (via tty->driver.write, line 1170 in n_tty.c) to return before all the data is processed. The task is then placed into TASK_INTERRUPTIBLE, and hits schedule at the bottom of the loop where there is now no "automatic" way to re-awake the process - unfortunately the console will never say "I can accept more characters" via the tty->write_wait wait queue. The console code does not appear to be setting the task to TASK_RUNNING, so I can only presume that it worked with previous kernels because it was relying on the page fault from copy_from_user to set the task back to the running state. Thinking about it a little more, isn't there a race condition there? The task is set to "RUNNING" and tty->driver.write is called. It gobbles up, say, 50% of the data and returns. Meanwhile, the device has processed that data and signals it via the write_wait queue. The task is set to "INTERRUPTIBLE" and hits schedule, to sleep indefinitely. Any comments? _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rm...@ar... --- --- | | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to maj...@vg... Please read the FAQ at http://www.tux.org/lkml/ |
|
From: James S. <jsi...@ac...> - 2000-03-19 03:12:50
|
On Fri, 17 Mar 2000, Eric S. Raymond wrote: > James A Simmons <jsi...@ac...>: > > No problem. Thats why we are all working together. I posted the latency > > patch I recieved. Petr pointed out things about it. Thanks Petr. I haven't > > heard from Eric. Eric ready to break and build new things. > > I'm done for the moment. I posted Sapphire and Emerald to linux-kernel. > Now to wait and see if they make it into the next kernel release. Okay. I hope it gets in too :) I'm already adding stuff for ruby. Vojtech will be adding stuff soon. So things are full steam ahead. I have been writing code all day. Still got more to go. "Look it's a text editor, no it's a OS, no it's Emacs" James Simmons ____/| fbdev/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U |
|
From: Petr V. <van...@vc...> - 2000-03-19 01:09:10
|
On Fri, Mar 17, 2000 at 03:13:40PM +0100, Pavel Machek wrote:
> > > From: Pavel Machek <pa...@su...>
> > > To: lin...@bu..., lin...@su..., mi...@ch...,
> > > jsi...@ac...
> > > PS: Would it be possible to declare that fbcon is re-entrant, but may
> > > mess the screen up in such case?
> > No. Accesses to accelerators cannot be interrupted. But it is possible
> > to place down_trylock around them...
> Well, then critical sections around accelerator could be wrapped in
> spin_lock_irq...
It is not good idea. Accelerated operation can be very long.
> > > + * Bigger buffer means better console writing performance, but worse
> > > + * latency of console switches.
> > > -char con_buf[PAGE_SIZE];
> > > -#define CON_BUF_SIZE PAGE_SIZE
> > > +#define CON_BUF_SIZE (PAGE_SIZE/10)
> > > +char con_buf[CON_BUF_SIZE];
> > Is not 400 too small? It is ~3 lines...
> No. Scrolling 3 lines takes _lots_ of time.
Under normal setups no scrolling occurs (i.e. hardware panning is used).
> > > +static int softint_missed = 0;
> > > -static void console_softint(unsigned long ignored)
> > > +static void console_softint(unsigned long ignored)
> > > +{
> > > + run_task_queue(&con_task_queue);
> > > + softint_missed = 1;
> > > + if (down_trylock(&console_sem)) {
> > > + printk( "console_softint request dropped\n" );
> > Is it really good idea to do printk() when console_sem is held?
> Yes. It _must_ work that way.
With current code you cannot do printk() from fbcon/fbdev (because of
console_lock is held, so on SMP deadlocks occurs on printk()), so if
your code fixes it, fine.
> > > - spin_unlock_irq(&console_lock);
> > > ret = copy_to_user(buf, con_buf_start, orig_count);
> > You do not have to have locked console here... You need only
> I know, but I do not care: copy_from_user is faster operation than
> scrolling.
I'm sorry. As we are probably holding big kernel lock here anyway,
there is no reason for unlock console_sem (except to allow console_softint
to run?)
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Pavel M. <pa...@su...> - 2000-03-18 19:47:33
|
Hi!
> > From: Pavel Machek <pa...@su...>
> > To: lin...@bu..., lin...@su..., mi...@ch...,
> > jsi...@ac...
> > PS: Would it be possible to declare that fbcon is re-entrant, but may
> > mess the screen up in such case?
> No. Accesses to accelerators cannot be interrupted. But it is possible
> to place down_trylock around them...
Well, then critical sections around accelerator could be wrapped in
spin_lock_irq...
> > + * Bigger buffer means better console writing performance, but worse
> > + * latency of console switches.
> > -char con_buf[PAGE_SIZE];
> > -#define CON_BUF_SIZE PAGE_SIZE
> > +#define CON_BUF_SIZE (PAGE_SIZE/10)
> > +char con_buf[CON_BUF_SIZE];
> Is not 400 too small? It is ~3 lines...
No. Scrolling 3 lines takes _lots_ of time.
> > +static int softint_missed = 0;
> > -static void console_softint(unsigned long ignored)
> > +static void console_softint(unsigned long ignored)
> > +{
> > + run_task_queue(&con_task_queue);
> > + softint_missed = 1;
> > + if (down_trylock(&console_sem)) {
> > + printk( "console_softint request dropped\n" );
> Is it really good idea to do printk() when console_sem is held?
Yes. It _must_ work that way.
> > - spin_unlock_irq(&console_lock);
> > ret = copy_to_user(buf, con_buf_start, orig_count);
> You do not have to have locked console here... You need only
I know, but I do not care: copy_from_user is faster operation than
scrolling.
> exclusive access to console copy buffer, but not to console
> code itself. All code should check for console changes as copy_to_user
> can sleep (and vc_screen copy to/from vcs does this checks).
Pavel
--
I'm pa...@uc.... "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents me at di...@li...
|
1998 messages has been excluded from this view by a project administrator.
