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: Brad H. <bh...@bi...> - 2002-09-12 07:32:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The proc interface for the input subsystem current provides entries like this in /proc/bus/input/devices: I: Bus=0003 Vendor=046d Product=c002 Version=0120 N: Name="Logitech USB-PS/2 Mouse M-BA47" P: Phys=usb-00:01.2-2.2/input0 D: Drivers=mouse0 event2 B: EV=7 B: KEY=f0000 0 0 0 0 0 0 0 0 B: REL=103 I think that the D: line is wrong. Those aren't really drivers, they are the handlers. Driver is a concept associated with the input_register_device() call (so it'd be more like hid or atkbd or whatever). I guess knowing the drivers might be useful eventually, although you can normally deduce it from a combination of the P: and N: lines. The attached patch does the trivial relabelling. Please apply to your tree and send to Linus if OK. BTW: I thought about doing a Handler/Handlers test based on the number of handlers, but that might make parsing the /proc entries harder. So not this time. Brad - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9gEG7W6pHgIdAuOMRAprOAKC5Ce0Xf8eWel9LUCIAAP7oTKDoKwCdFvyC Bj8mHFI1IViAOrIW7Nx3Fqg= =AzYI -----END PGP SIGNATURE----- |
From: Aivils S. <Aiv...@un...> - 2002-09-10 11:25:29
|
>> >> >Agreed - I also use 24 or 36 virtual terminals on one head regularily.. it >> >would be really bad if the limit would be lowered to such a unusable >> number >> >like 16 :-(. >> Some guys with small IQ use one virtual console per virtual terminal. >> Mine to :))) > >We are not talking about number of virtual console per virtual terminal >(whatever it is - I always thought that virtual console is wrong term >for virtual terminal, and so there is inherent 1:1 relation). > >Do you say that if you hit alt-f2, nothing will happen? That's >what we are talking about... Even smallest system I know uses 2: one >for text terminal, and another for X running (if I'll not count system >which has zero of them). > >Besides that 'I do not need that' is not valid argument. Same way I can >say that I do not need anything else than matroxfb, so lets remove >other drivers, other architectures than ia32... I will illustrate total difference of X and fb users (dead way discussion). If MAX_NR_CONSOLES create limitations , that must be configurable. James Simons kernel patches realy allow run N independ-input-output XFree servers with N /dev/tty's , whats realy happen in may home system. If James Simons menace all Linux folks, of course You should restrict he :) Aivils |
From: Petr V. <VAN...@vc...> - 2002-09-10 10:43:59
|
On 10 Sep 02 at 13:23, Aivils Stoss wrote: > > >Agreed - I also use 24 or 36 virtual terminals on one head regularily.. it > >would be really bad if the limit would be lowered to such a unusable > number > >like 16 :-(. > Some guys with small IQ use one virtual console per virtual terminal. > Mine to :))) We are not talking about number of virtual console per virtual terminal (whatever it is - I always thought that virtual console is wrong term for virtual terminal, and so there is inherent 1:1 relation). Do you say that if you hit alt-f2, nothing will happen? That's what we are talking about... Even smallest system I know uses 2: one for text terminal, and another for X running (if I'll not count system which has zero of them). Besides that 'I do not need that' is not valid argument. Same way I can say that I do not need anything else than matroxfb, so lets remove other drivers, other architectures than ia32... Petr Vandrovec van...@vc... |
From: Aivils S. <Aiv...@un...> - 2002-09-10 10:23:32
|
>Agreed - I also use 24 or 36 virtual terminals on one head regularily.. it >would be really bad if the limit would be lowered to such a unusable number >like 16 :-(. Some guys with small IQ use one virtual console per virtual terminal. Mine to :))) Aivils end-user |
From: Petr B. <pa...@pa...> - 2002-09-07 08:21:32
|
Dear diary, on Tue, Aug 27, 2002 at 10:12:27PM CEST, I got a letter, where Petr Vandrovec <VAN...@vc...> told me, that... > > desktop. We will have 16 instead of 64. The second change which I don't > > I'm already using 25 virtual terminals on one head (*). 64 is low, but > 16 is unusable. I could imagine changing code to allow for unlimited > number of virtual terminals per one desktop, but going down to 16? > Petr Vandrovec > van...@vc... > > (*) ctrl-leftalt-f1..f12, ctrl-rightalt-f1..f12, plus alt-leftarrow > from VT1 to reach fullscreen VMware... Some of VT's display progress > of different processes (teletext grabber, rc5des, syslog, ...), > and rest of them I use for real work. I already ran out of 24 VTs > few times in the past, but it never bothered me enough to learn kernel > about windows-f1..f12 being vt25..36. Agreed - I also use 24 or 36 virtual terminals on one head regularily.. it would be really bad if the limit would be lowered to such a unusable number like 16 :-(. -- Petr "Pasky" Baudis * ELinks maintainer * IPv6 guy (XS26 co-coordinator) * IRCnet operator * FreeCiv AI occassional hacker . <Beeth> Girls are like internet domain names, the ones I like are already taken. <honx> Well, you can still get one from a strange country :-P . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ |
From: Aivils S. <Aiv...@un...> - 2002-09-05 08:03:49
|
Hi, folks Now this one available: http://startx.times.lv/bruby-2.4.19-20020905.diff.bz2 Improved stability with proper vt-handling initialization. usb-hid synced with 2.5.31 sync with ruby CVS. I do not full input backport from 2.5.31. May be I lost same active developed Force-Feedback changes. Aivils |
From: Aivils S. <Aiv...@un...> - 2002-09-02 14:37:22
|
Hi Here bug to lead oops. My show up depend hardware and console count. Without this patch I get message: Uncompressing Linux kernel invalid compressed format (err=2) -- system halted and more various oops. After patch I get normal ruby. kmalloc not change memory content. vty_driver->termios stay undefined. Later in init_dev() tty_io.c termios checking going to wrong way and kernel oops. --- ruby/linux/drivers/char/vt.c Sat Jul 27 22:33:27 2002 +++ linr/drivers/char/vt.c Mon Sep 2 20:00:37 2002 @@ -1602,12 +1603,18 @@ void vt_map_input(struct vt_struct *vt) vty_driver->table = kmalloc(sizeof(struct tty_struct) * MAX_NR_USER_CONSOLES, GFP_KERNEL); + memset(vty_driver->table, + 0, sizeof(struct tty_struct) * MAX_NR_USER_CONSOLES); vty_driver->termios = kmalloc(sizeof(struct termios) * MAX_NR_USER_CONSOLES, GFP_KERNEL); + memset(vty_driver->termios, + 0, sizeof(struct termios) * MAX_NR_USER_CONSOLES); vty_driver->termios_locked = kmalloc(sizeof(struct termios) * MAX_NR_USER_CONSOLES, GFP_KERNEL); + memset(vty_driver->termios_locked, + 0, sizeof(struct termios) * MAX_NR_USER_CONSOLES); vty_driver->magic = TTY_DRIVER_MAGIC; vty_driver->name = "vc/%d"; Aivils |
From: James S. <jsi...@in...> - 2002-08-29 23:30:25
|
Hi! The console code from Dave Jones tree has been updated to the latest input changes. Could you intergrate into your BK tree. I have tested on my local system. It has many of the fixes that have been posted. Note this is the last large change. http://linuxconsole.bkbits.net:8080/dev Thank you. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
From: James S. <jsi...@in...> - 2002-08-28 18:58:36
|
Its is easy if your keyboard driver is based on the input api. Just use the /dev/input/event interface. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net On Mon, 26 Aug 2002, Kai-Boris Schad wrote: > Hi ! > > I'm trying to set up a small embedded system for gps receiving with a linux > system. I want to have the system working without a graphics card - wich > works well. The Problem I have at the moment is to access the keyboard > without a graphics card, because the console driver does not start then ( > Also a redirect doesn't work then :-( ) > Is there a way to access the keyboard in this case by a user program ? > The system recognises the keyboard ( I think Kernel and init) and reacts if > ctrl-alt-del is pressed. > > Thanks for your help ! > > Kai > > -- > Kai-Boris Schad > University of Ulm, Germany > Dept. of Electron Devices and Circuits > Integrated Circuits in Communications > Albert Einstein Allee 45 > 89069 ULM > > http://www.uni-ulm.de/icic > email:ks...@eb... > phone +49/731/50-31581 fax +49/731/50-31599 > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > |
From: Petr V. <VAN...@vc...> - 2002-08-27 20:12:48
|
On 27 Aug 02 at 12:07, James Simmons wrote: > > Is this going to be possible in the new kernel console code? Is there a > > list of new API changes/capabilities for the new linuxconsole yet? > > Yes it will be possible. You will also be able to resize the resolution > per vc. I don't have a list of API changes yet. The userland interface is > pretty much the same. The difference is the number of consoles per Userland interface must be same. Current userland interface already allows for all mentioned here, so there is no need to invent new one. > desktop. We will have 16 instead of 64. The second change which I don't I'm already using 25 virtual terminals on one head (*). 64 is low, but 16 is unusable. I could imagine changing code to allow for unlimited number of virtual terminals per one desktop, but going down to 16? Petr Vandrovec van...@vc... (*) ctrl-leftalt-f1..f12, ctrl-rightalt-f1..f12, plus alt-leftarrow from VT1 to reach fullscreen VMware... Some of VT's display progress of different processes (teletext grabber, rc5des, syslog, ...), and rest of them I use for real work. I already ran out of 24 VTs few times in the past, but it never bothered me enough to learn kernel about windows-f1..f12 being vt25..36. |
From: James S. <jsi...@in...> - 2002-08-27 19:16:10
|
> I am reviewing bugs for console-tools on Debian. > > fb allows the user to set the font on a per-vc basis; this is not > possible on the current Kernel AFAIK. Correct. When you change the font it changes all the VCs. Same for resizing the screen via the VT layer. > Is this going to be possible in the new kernel console code? Is there a > list of new API changes/capabilities for the new linuxconsole yet? Yes it will be possible. You will also be able to resize the resolution per vc. I don't have a list of API changes yet. The userland interface is pretty much the same. The difference is the number of consoles per desktop. We will have 16 instead of 64. The second change which I don't know if it will go into 2.5.X is tty0 being the foreground console will go away. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
From: Alastair M. <mck...@co...> - 2002-08-27 13:46:55
|
Hello Console experts! I am looking for a good technique for detecting whether /dev/console is a serial console; one that works on current 2.2/2.4 kernels and will remain working in the new framework. Currently there is a bug against using tty | grep ttyS=20 as unreliable, as at this point during boot in user space, we're running on /dev/console whether screen or console is in use. Can anyone name a better solution? one solution is to write a program to use ioctl(TIOCGSERIAL) (setserial can't be guaranteed to be there). Thanks, Alastair McKinstry --=20 Alastair McKinstry <mck...@co...> Mobile: +353 87 6847928 Saorl=E9ir - Software Services, www.saorleir.com Office: +353 91 556177 Fax: +353 91 556177 GPG Key fingerprint =3D 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 |
From: Alastair M. <mck...@co...> - 2002-08-27 13:46:54
|
Hello, I am reviewing bugs for console-tools on Debian. fb allows the user to set the font on a per-vc basis; this is not possible on the current Kernel AFAIK. Is this going to be possible in the new kernel console code? Is there a list of new API changes/capabilities for the new linuxconsole yet? Thanks, Alastair McKinstry --=20 Alastair McKinstry <mck...@co...> Mobile: +353 87 6847928 Saorl=E9ir - Software Services, www.saorleir.com Office: +353 91 556177 Fax: +353 91 556177 GPG Key fingerprint =3D 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 |
From: Henrion B. <bh...@ud...> - 2002-08-20 15:46:45
|
Hello, I'm trying to build a computer with 2 screens, 2 keybs, 2 mouses, and 2 graphics cards (1 AGP and 1PCI-RivaTNT2). The 2 keybs (1AT and 1USB) and the 2 mouses (1PS2 and 1USB) works with the kernel 2.5.31, but I cannot find a way to compile the riva module, to support the second PCI card. It is not ready in the latest kernel? (I use make menuconfig, and do not see the 'Video' menu in it, but the code is in the sources). Can you help me? -- Benjamin Henrion <bh...@ud...> http://bh.udev.org |
From: <joh...@it...> - 2002-08-19 07:33:26
|
Henrion Benjamin writes: > Does somebody has succeeded in building a 2.5.27 with the current ruby > CVS? Perhaps trying with the latest 2.5 kernel will be easier. The KEY_PLAY redefinition is fixed in linus' kernel. A large part of the linuxconsole tree was integrated into the mainline kernel. Maybe you don't have to use the linuxconsole cvs. > > If yes, can you provide your .config file? (I try to compile a kernel as > much as generic as possible, a lot of things as modules, and with > RivaTNT and usb keyb support) > > I attach a report of my problem in attachment... > > Thanks, > > -- > Benjamin Henrion <bh...@ud...> > http://bh.udev.org > make[1]: Entering directory `/usr/src/linux-2.5.27/kernel' > gcc -Wp,-MD,./.suspend.o.d -D__KERNEL__ -I/usr/src/linux-2.5.27/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=suspend -DEXPORT_SYMTAB -c -o suspend.o suspend.c > In file included from /usr/src/linux-2.5.27/include/linux/keyboard.h:5, > from /usr/src/linux-2.5.27/include/linux/kbd_kern.h:5, > from /usr/src/linux-2.5.27/include/linux/vt_kern.h:13, > from suspend.c:47: > /usr/src/linux-2.5.27/include/linux/input.h:457: warning: `KEY_PLAY' redefined > /usr/src/linux-2.5.27/include/linux/input.h:310: warning: this is the location of the previous definition > /usr/src/linux-2.5.27/include/linux/input.h:461: warning: `KEY_FASTFORWARD' redefined > /usr/src/linux-2.5.27/include/linux/input.h:311: warning: this is the location of the previous definition > suspend.c:293: warning: #warning This might be broken. We need to somehow wait for data to reach the disk > In file included from suspend.c:47: > /usr/src/linux-2.5.27/include/linux/vt_kern.h:232: field `vt_tq' has incomplete type > /usr/src/linux-2.5.27/include/linux/vt_kern.h: In function `set_console': > /usr/src/linux-2.5.27/include/linux/vt_kern.h:245: warning: implicit declaration of function `schedule_task' > suspend.c: In function `prepare_suspend_processes': > suspend.c:602: warning: implicit declaration of function `sys_sync' > suspend.c: In function `bdev_write_page': > suspend.c:1007: warning: unused variable `bh' > suspend.c:1024: warning: control reaches end of non-void function > suspend.c: At top level: > suspend.c:100: warning: `orig_fgconsole' defined but not used > suspend.c:100: warning: `orig_kmsg' defined but not used > make[1]: *** [suspend.o] Error 1 > make[1]: Leaving directory `/usr/src/linux-2.5.27/kernel' > make: *** [kernel] Error 2 |
From: Henrion B. <bh...@ud...> - 2002-08-18 20:50:59
|
Does somebody has succeeded in building a 2.5.27 with the current ruby CVS? If yes, can you provide your .config file? (I try to compile a kernel as much as generic as possible, a lot of things as modules, and with RivaTNT and usb keyb support) I attach a report of my problem in attachment... Thanks, -- Benjamin Henrion <bh...@ud...> http://bh.udev.org |
From: Mark H. <Mar...@xs...> - 2002-08-14 23:21:18
|
Hi all, I've been following this list for some time now, and am quite anxious to try this new console system, however, all my efforts have been unsuccessfull. I must have some kernel setting wrong, since I can get all but the console working in the 2.5.31 kernel, I keep getting "unable to open /dev/tty0'' messages (also for tty's 1-5), and thus can't login from console (ssh login works fine). I've been going through the inormation on=20 sf.net/projects/linuxconsole several times now,=20 but can't seem to locate my error. I would greatly appreciate if someone can take=20 a look at my .config (attached) and point out my mistake. (I'm using a ps/2 keyboard/mouse, and a Geforce2=20 graphics card). Thanks, Mark. P.S. Great progress so far, keep up the good work! |
From: James S. <jsi...@tr...> - 2002-08-06 04:48:56
|
Due to the company I was working for going under my email address has changed. My permanent address is jsi...@us.... This will go where ever I read my email from. My personal private account is cap...@ya.... Please DONT email me at transvirtual.com any more. Sorry about the inconvince. Thank you. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
From: James S. <jsi...@tr...> - 2002-08-02 14:34:40
|
This patch brings the console system up to date with the DJ tree. Still more to come. It fixes several bugs including the devfs one. Please apply. http://linuxconsole.bkbits.net/dev arch/mips/au1000/common/serial.c | 2 arch/parisc/kernel/pdc_cons.c | 3 arch/ppc/4xx_io/serial_sicc.c | 2 arch/ppc/8xx_io/uart.c | 2 arch/ppc64/kernel/ioctl32.c | 64 arch/sparc64/kernel/ioctl32.c | 23 arch/x86_64/ia32/ia32_ioctl.c | 20 drivers/char/Makefile | 12 drivers/char/console.c | 3032 --------------------------------------- drivers/char/console_macros.h | 161 +- drivers/char/consolemap.c | 136 - drivers/char/decvte.c | 2054 ++++++++++++++++++++++++++ drivers/char/hvc_console.c | 2 drivers/char/keyboard.c | 605 ++++--- drivers/char/misc.c | 1 drivers/char/selection.c | 63 drivers/char/sysrq.c | 22 drivers/char/tty_io.c | 7 drivers/char/vc_screen.c | 115 + drivers/char/vt.c | 2756 +++++++++++++++++++++-------------- drivers/char/vt_ioctl.c | 1441 ++++++++++++++++++ drivers/s390/char/ctrlchar.c | 2 drivers/tc/zs.c | 2 drivers/video/dummycon.c | 1 drivers/video/fbcon.c | 55 drivers/video/mdacon.c | 21 drivers/video/newport_con.c | 1 drivers/video/promcon.c | 33 drivers/video/sticon-bmode.c | 2 drivers/video/sticon.c | 3 drivers/video/vgacon.c | 21 include/linux/console.h | 17 include/linux/console_struct.h | 110 - include/linux/consolemap.h | 6 include/linux/kbd_kern.h | 27 include/linux/selection.h | 23 include/linux/tty.h | 8 include/linux/vt_kern.h | 275 ++- include/video/fbcon.h | 2 39 files changed, 6214 insertions(+), 4918 deletions(-) . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
From: James S. <jsi...@tr...> - 2002-08-01 17:27:01
|
> A quick read through reveals: > > - printk("mdacon: MDA card not detected.\n"); > + printk("KERN_WARNING mdacon: MDA card not detected.\n"); > > KERN_WARNING and friends should be outside the quotes. Fixed. > Secondly, the absolutely gigantic "switch (vc_state) {" stuff with > extra layers of switch statements below it in decvte.c - I find this > rather disgusting to read. I bet the resulting asm is also disgusting. > Isn't there a cleaner solution to this? (I've been carrying around > since 2.2 patches to the console layer to split this up mainly because > some older versions of ARM gcc choked on it. I'm not certain about > current versions though.) Yes it is disgusting. That is one of the reasons I placed it into a seperate file. It is the same code as before. Could you send me that patch. I'm interested in it :-) > Also, something that should probably be fixed one day, but I wouldn't > call it a show stopper: > > -#define SIZE(x) (sizeof(x)/sizeof((x)[0])) > +#define SIZE(x) (sizeof(x)/sizeof((x)[0])) > > We have ARRAY_SIZE(x) in linux/kernel.h which does this already. Done. |
From: Pavel M. <pa...@el...> - 2002-08-01 12:08:10
|
Hi! > > > > ICBW, but wasn't uint<n>_t only promised to be at least <n> bits? > > As the matter of fact, IHBW. pavel@Elf:~$ wtf ICBW Gee... I don't know what ICBW means... pavel@Elf:~$ wtf IHBW Gee... I don't know what IHBW means... pavel@Elf:~$ Would you care to submit patch for wtf(6)? ;-) 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 at di...@li... |
From: Russell K. <rm...@ar...> - 2002-07-31 23:00:17
|
On Wed, Jul 31, 2002 at 03:27:57PM -0700, James Simmons wrote: > Here is the second patch. It has many fixes and alot of major changes > internally. A quick read through reveals: - printk("mdacon: MDA card not detected.\n"); + printk("KERN_WARNING mdacon: MDA card not detected.\n"); KERN_WARNING and friends should be outside the quotes. Secondly, the absolutely gigantic "switch (vc_state) {" stuff with extra layers of switch statements below it in decvte.c - I find this rather disgusting to read. I bet the resulting asm is also disgusting. Isn't there a cleaner solution to this? (I've been carrying around since 2.2 patches to the console layer to split this up mainly because some older versions of ARM gcc choked on it. I'm not certain about current versions though.) Also, something that should probably be fixed one day, but I wouldn't call it a show stopper: -#define SIZE(x) (sizeof(x)/sizeof((x)[0])) +#define SIZE(x) (sizeof(x)/sizeof((x)[0])) We have ARRAY_SIZE(x) in linux/kernel.h which does this already. -- Russell King (rm...@ar...) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html |
From: James S. <jsi...@tr...> - 2002-07-31 22:28:05
|
Here is the second patch. It has many fixes and alot of major changes internally. Please test it out. It will break a few keyboard drivers due to the struct kbd_struct changes. It will also break a few framebuffer drivers as well since they touch console data structures. If you port your fbdev driver to the new api you will not have to worry about this (reason I developed this new api) :-) arch/mips/au1000/common/serial.c | 2 arch/parisc/kernel/pdc_cons.c | 3 arch/ppc/4xx_io/serial_sicc.c | 2 arch/ppc/8xx_io/uart.c | 2 arch/ppc64/kernel/ioctl32.c | 64 arch/sparc64/kernel/ioctl32.c | 23 arch/x86_64/ia32/ia32_ioctl.c | 20 drivers/char/Makefile | 12 drivers/char/console.c | 3032 ------------------------------- drivers/char/console_macros.h | 161 - drivers/char/consolemap.c | 136 - drivers/char/decvte.c | 2054 +++++++++++++++++++++ drivers/char/hvc_console.c | 2 drivers/char/keyboard.c | 595 +++--- drivers/char/misc.c | 1 drivers/char/selection.c | 63 drivers/char/sysrq.c | 22 drivers/char/tty_io.c | 2 drivers/char/vc_screen.c | 115 - drivers/char/vt.c | 2753 +++++++++++++++++----------- drivers/char/vt_ioctl.c | 1443 ++++++++++++++ drivers/s390/char/ctrlchar.c | 2 drivers/tc/zs.c | 2 drivers/video/dummycon.c | 1 drivers/video/fbcon-accel.c | 5 drivers/video/fbcon.c | 55 drivers/video/mdacon.c | 21 drivers/video/newport_con.c | 1 drivers/video/promcon.c | 33 drivers/video/sticon-bmode.c | 2 drivers/video/sticon.c | 3 drivers/video/vgacon.c | 21 include/linux/console.h | 17 include/linux/console_struct.h | 110 - include/linux/consolemap.h | 6 include/linux/kbd_kern.h | 27 include/linux/selection.h | 23 include/linux/tty.h | 8 include/linux/vt_kern.h | 275 ++ include/video/fbcon.h | 2 45 files changed, 6214 insertions(+), 4923 deletions(-) diff: http://www.transvirtual.com/~jsimmons/console.diff.gz BK: http://linuxconsole.bkbits.net:8080/dev . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
From: David W. <dw...@in...> - 2002-07-31 11:45:12
|
vo...@su... said: > On Wed, Jul 31, 2002 at 11:07:21AM +0100, David Woodhouse wrote: > > vo...@su... said: > > > Ok. Is the use in drivers/input/serio.c buggy? > > > > If it matters that the thread can miss wakeup events and sleep > > indefinitely while there's a 'SERIO_RESCAN' event pending, then > > yes it looks buggy. <...> > Thanks for the explanation. Yes, this could happen. Quod Erat Demonstrandum. Even people who can be assumed to have a clue can make the mistake of using sleep_on() in spite of the fact that it's almost impossible to use correctly. It can be removed from 2.5 without much pain -- half the drivers are broken anyway due to the removal of cli(). I'm running a kernel with sleep_on() removed quite happily. At Stephen's request, I'll wait a couple of days for ext3 to remove all use of sleep_on() before submitting the patch. NFS wants fixing too, but other than that the breakage seems remarkably slight. -- dwmw2 |
From: David W. <dw...@in...> - 2002-07-31 10:17:39
|
vo...@su... said: > Ok. Is the use in drivers/input/serio.c buggy? If it matters that the thread can miss wakeup events and sleep indefinitely while there's a 'SERIO_RESCAN' event pending, then yes it looks buggy. serio_thread() serio_rescan() -------------- -------------- serio_handle_events(); serio->event |= SERIO_RESCAN; wake_up(&serio_wait); sleep_on(&serio_wait); ...sleeps... If both serio_thread() and serio_rescan() hold the BKL you're OK. It looks like serio_rescan() doesn't, though. > What should be it replaced with? In general, the response 'anything but sleep_on' is considered appropriate. Try wait_event(). -- dwmw2 |