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: Steffen S. <s.s...@ph...> - 2000-08-08 14:52:23
|
James Simmons wrote: > > BTW, it's fun to say rude things about the console code but we should > > understand that it is a difficult problem. Memory-mapped video displays are > > schizophrenic: they are character devices and hence should talked to via > > queues. But they're fast and random access, so we also want synchronous > > write semantics. But they're stateful so we end up where we are today. > > Oh its quite a challenge. Everytime I think I solved a problem I > discover another limitation of the console system. The code is very old > and is completely designed around the idea of the VGA text mode hardware. At least these are words from a kernel developer. I hope this increases the chances for them to be heard... > What is even worst is the whole vidoe subsystem. We have DRI/fbdv and > v4l all running independent of each other but yet each subsystem can have > a impact on other apps using the other 2 subsystems. Then we have the > console angle. So when thinking about the console design I have to take in > consideration the other video subsystems of linux as well. What a job but > it is well worth it. How true. And unfortunately I know what you are talking about... :-)) Strangely enough, developing KGI I made the same experiences, except probably being demotivated more often by the 'officials'. [Note: The following is not meant offensive in any way.] I am glad to read this as at least it shades a more objective and less emotionally light on the approach taken by the GGI/KGI project (http://www.ggi-project.org, http://kgi.sourceforge.net). The essential concepts of KGI proposed in 1996 (see http://www2.linuxjournal.com/lj-issues/issue31/0160.html) are in the new console code now. You have kernel-space video drivers (fbdev), input hardware drivers (the input interface) and a management code (the new console code). Congratulations for that. > > Good luck with the console project in 2.5 :) I wish you good luck too. Anyhow, KGI development is still active, and anyone willing to join is very welcome. > Innovation, innovate, and the concept of doing what everyone else did 20 > years ago are registered trademarks of Microsoft Corporation. Other > buzzwords, euphemisms, and blatant lies are trademarks of their respective > owners. Nice signature. I really like it! :-)) Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... TU-Chemnitz http://www.tu-chemnitz.de/~sse |
|
From: James S. <jsi...@ac...> - 2000-08-07 14:29:53
|
Hi! I fixed the annoying printk bug in CVS. The only bug left now is the ctrl alt del bug. For some reason I can only press ctrl alt del on the first VC without crashing the machine. Their it will reboot. If I attempt a reboot from any other VC the machine crashes. From the oops it claims to crash in k_shift. If I comment out ctrl_alt_del() it doesn't crash. Do you have any idea why it crashes like this. -------------------------------------------------------------------------- Innovation, innovate, and the concept of doing what everyone else did 20 years ago are registered trademarks of Microsoft Corporation. Other buzzwords, euphemisms, and blatant lies are trademarks of their respective owners. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-08-07 01:00:48
|
On Sun, 6 Aug 2000, Franz Sirl wrote: > On Sat, 05 Aug 2000, James Simmons wrote: > > How far along is the ADB code? > > Sorry, I'm a bit behind my schedule and I'll be mostly offline til 15th Aug. > I checked in the adbhid.c I have in the Linux/PPC Bitkeeper tree. It seems to > work fine for most users, but I still have some refinements in mind. > > More when I'm back. Okay. Thanks for the info. I have to stump out a nasty bug in the console code. I can't figure out for teh life of me what is causing this bug. Innovation, innovate, and the concept of doing what everyone else did 20 years ago are registered trademarks of Microsoft Corporation. Other buzzwords, euphemisms, and blatant lies are trademarks of their respective owners. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-08-07 00:48:27
|
> > > Yup. console can block _interrupts_ for 2 millisecs, which is much worse > > > than scheduling delays (network Rx overruns). > > > > I have been thinking on how to deal with this as well. In do_con_write it > > breaks up the writes into CON_BUF_SIZE. During each loop we could test for > > current->need_sched. Break the lock if needed and schedule() then reset > > the console lock. To prevent lost messages we could even use the > > con_task_queue. > > mm.. There are two fairly separate requirements here - the first is to not > block interrupts for so long. The need_resched/schedule() requirement is > icing on that cake and IMO comes a long way behind in importance. I guess > you can bird both these stones at the same time. Oops. I was thinking of the problems with latency when you cat a big file to a tty. Especially with a fbdev driver. As for the interrupt latency. I will have to work on that. > BTW, it's fun to say rude things about the console code but we should > understand that it is a difficult problem. Memory-mapped video displays are > schizophrenic: they are character devices and hence should talked to via > queues. But they're fast and random access, so we also want synchronous > write semantics. But they're stateful so we end up where we are today. Oh its quite a challenge. Everytime I think I solved a problem I discover another limitation of the console system. The code is very old and is completely designed around the idea of the VGA text mode hardware. Now that linux supports many kinds of hardware it was a matter of rethinking the abstracting of the console system. Especially if we want to take advantage of the video hardware we have today. It is not that much of a leap tho. What is even worst is the whole vidoe subsystem. We have DRI/fbdv and v4l all running independent of each other but yet each subsystem can have a impact on other apps using the other 2 subsystems. Then we have the console angle. So when thinking about the console design I have to take in consideration the other video subsystems of linux as well. What a job but it is well worth it. > Good luck with the console project in 2.5 :) Thanks. It should be another month before it is really ready for mass testing. Innovation, innovate, and the concept of doing what everyone else did 20 years ago are registered trademarks of Microsoft Corporation. Other buzzwords, euphemisms, and blatant lies are trademarks of their respective owners. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Franz S. <Fra...@la...> - 2000-08-06 19:09:38
|
On Sat, 05 Aug 2000, James Simmons wrote: > How far along is the ADB code? Sorry, I'm a bit behind my schedule and I'll be mostly offline til 15th Aug. I checked in the adbhid.c I have in the Linux/PPC Bitkeeper tree. It seems to work fine for most users, but I still have some refinements in mind. More when I'm back. Franz. |
|
From: Andrew M. <an...@uo...> - 2000-08-05 02:06:59
|
James Simmons wrote: > > > > > - I haven't tested fbdev - Pavel says it's bad. > > > > > > thats pretty unsolvable (just as the serial console latencies), the > > > console layer assumes atomicity. > > > > Yup. console can block _interrupts_ for 2 millisecs, which is much worse > > than scheduling delays (network Rx overruns). > > I have been thinking on how to deal with this as well. In do_con_write it > breaks up the writes into CON_BUF_SIZE. During each loop we could test for > current->need_sched. Break the lock if needed and schedule() then reset > the console lock. To prevent lost messages we could even use the > con_task_queue. mm.. There are two fairly separate requirements here - the first is to not block interrupts for so long. The need_resched/schedule() requirement is icing on that cake and IMO comes a long way behind in importance. I guess you can bird both these stones at the same time. BTW, it's fun to say rude things about the console code but we should understand that it is a difficult problem. Memory-mapped video displays are schizophrenic: they are character devices and hence should talked to via queues. But they're fast and random access, so we also want synchronous write semantics. But they're stateful so we end up where we are today. Good luck with the console project in 2.5 :) |
|
From: James S. <jsi...@ac...> - 2000-08-05 01:03:22
|
How far along is the ADB code? Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-08-05 00:09:44
|
> > > - I haven't tested fbdev - Pavel says it's bad. > > > > thats pretty unsolvable (just as the serial console latencies), the > > console layer assumes atomicity. > > Yup. console can block _interrupts_ for 2 millisecs, which is much worse > than scheduling delays (network Rx overruns). I have been thinking on how to deal with this as well. In do_con_write it breaks up the writes into CON_BUF_SIZE. During each loop we could test for current->need_sched. Break the lock if needed and schedule() then reset the console lock. To prevent lost messages we could even use the con_task_queue. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-08-02 23:56:09
|
Hi folks!! Good news. I found the bug causing me the problem with removing /dev/tty0 as the foreground console. Once I did this both libsvga and XF 4.0 worked!!!!!!! Yeah. me very happy. These apps worked with linux following more closely SYS V vt standards. The only app that didn't was mingetty. It will not allocate the first VT :-( Tomorrow I will find the code for mingetty and make a patch for it. Also I will need to start testing with console-tools package. I haven't tested with gpm yet. Will do tomorrow. A word of warning. Their is a bug in the VT console code (stuff that tells printk to print to the console). It prints only to the first console and you have to VC switch to the first console to have it properly reboot. Otherwise it hanges. I will fix this tomorrow. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-07-31 13:31:29
|
Anyone here a kernel configure expert. I just tested out the ruby tree with make config, make menuconfig, and make xconfig. The first two worked but make xconfig failed with [jsimmons@maxwell linux]$ make xconfig rm -f include/asm ( cd include ; ln -sf asm-i386 asm) make -C scripts kconfig.tk make[1]: Entering directory `/usr/src/linux-ruby/scripts' cat header.tk >> ./kconfig.tk ./tkparse < ../arch/i386/config.in >> kconfig.tk drivers/video/Config.in: 24: unknown command make[1]: *** [kconfig.tk] Error 1 make[1]: Leaving directory `/usr/src/linux-ruby/scripts' make: *** [xconfig] Error 2 Does anyone know a solution to this? Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-07-30 16:38:33
|
Hi! The CVS has been updated to test5 now. Right now I working on the following: In my local tree: Making linux SYSV VT switch complenent. Getting libsvga and XF4 working. Have to do alot of testing at home first. In CVS: Fbdev layer has been brought into sync. I unrolled alot of the big changes so only a few api changes have happened. Right now fbcon.c is very broken because of the big changes in the console system. Most likely I will finish this first. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-07-29 00:49:44
|
Hi! Thanks to Matan I got svgalib to run on ruby. It also helped me discover a few bugs. This includes what makes XF4 lock up. The raw mode code works fine. Linux does NOT follow SVS4 VT specs where ruby now does. VT 0 being the foreground console no longer makes sense in a multihead environment. This means /dev/tty0 will be going away. In fact this mismatch of the first VC being 0 and 1 is what was confussing X windows. So in the code at home I migrating everything over have the first VC 0 instead of 1. /dev/tty0 is going away. In doing so I managed to crash the kernel in the exact same way X has been. Now I go to find the problem. P.S I also have new code to sync up CVS vidoe layer with fbdev in the lastest kernel. I will be comitting this soon. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Matan Ziv-Av <ma...@sv...> - 2000-07-27 15:03:17
|
On Tue, 25 Jul 2000, James Simmons wrote: > I did some testing today. I tried out libsvga 1.4.1. It works great under > 2.2.X. Under 2.4.X it chokes about a mmap problem. I have seen this > reported before. Is their a patch for it? Svgalib background execution support depended on being able to mmap /self/proc/mem, which is notpossible since linux-2.3.27. The solution is to compile svgalib without background support. To do that get source distribution of svgalib, edit Makefile.cfg to comment out the line BACKGROUD = Y, and then recompile and reinstall svgalib. -- Matan Ziv-Av. ma...@sv... |
|
From: James S. <jsi...@ac...> - 2000-07-25 22:51:32
|
> Rawmode is best tested using showkey -s. Gave it a try. To bad you can't change the keyboard mode with it. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-07-25 22:49:01
|
I did some testing today. I tried out libsvga 1.4.1. It works great under 2.2.X. Under 2.4.X it chokes about a mmap problem. I have seen this reported before. Is their a patch for it? The next thing I tried was libgii. It also worked find for the keyboard ioctl I could trace. So I don't know yet what the problem is. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Vojtech P. <vo...@su...> - 2000-07-25 11:49:34
|
On Mon, Jul 24, 2000 at 10:53:01AM -0400, James Simmons wrote: > > Hi! > > I tested Xfree86 4.X on ruby. The results. It comes up but the raw key > doesn't work. No key presses showed up anywhere. I assume the raw keycode > has a bug. When I tried a xterm or kvt it locked my machine hard. > Any other programs that use raw key mode so I can test it. I think GGI > does but I'm not sure. Rawmode is best tested using showkey -s. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@ac...> - 2000-07-25 02:09:08
|
Hi! I tested Xfree86 4.X on ruby. The results. It comes up but the raw key doesn't work. No key presses showed up anywhere. I assume the raw keycode has a bug. When I tried a xterm or kvt it locked my machine hard. Any other programs that use raw key mode so I can test it. I think GGI does but I'm not sure. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@ac...> - 2000-07-25 00:09:03
|
Is this a good idea Vojtech ? Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net ---------- Forwarded message ---------- Date: Mon, 24 Jul 2000 13:19:03 -0700 (PDT) From: Eric Olson <ej...@ma...> To: lin...@vg... Subject: pc_keyb.c 3 button mouse emulation I would like to use the "Windows" key on my PC compatible notebook as the middle mouse button. I would prefer to do this at the driver level as is done on the Macintosh port rather than at the application level. The three button Macintosh mouse emulation is in mac_keyb.c. I would like to modify pc_keyb.c in a similar way so that I can generate psaux mouse clicks with the pc keyboard. I think this should be easy for someone who knows about such things, but I am not such a person. I know there is already three button emulation for two button mice in the form of simultaneously pressing both buttons. This is mostly usefull, but there are some damaged applications which have mouse clicks of the form press middle button (and hold it) and then press the left button, which, even with all my acquired two button dexterity, I cannot possibly manage with the current three button emulation. Anyway, I am hoping that one of the current maintainers of this code might see the use in such a feature and help. Since the ps/2 mouse and keyboard drivers are now part of the same file, this hack may not even be so ugly. If there is an existing way to do what I am wanting, then I apologize for this message, but would then like very much to know what that way is. All the best, Eric Olson, ej...@ma... - 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-07-24 00:37:22
|
> > I hope Linus will accept it. The split (drivers/usb + > > drivers/char/joystick) already is causing trouble. > > Any feedback from Linus yet? Nope. Waiting for test5-pre5 to see if he accepted it. > > Great. Well, you can send it even if it's not tested - ruby is a > > development tree, many things there don't event compile. Everything should compile. Not everything will work right :-( You don't need to set VT_EXTEND anymore. > > > I already said it and I say it again, I just _love_ the clean HID drivers > > > possible with the input layer :-). > > > > Thank you. You know, it really makes me happy hearing this. > > Well, that's the way I feel after working with the code. There are some minor > loose ends, but I really like the design. Me too. I love the /dev/input interface. I'm glad to see linux have a sane interface now. Just to get all the mice converted for 2.4.0. Q: Why did they deprecate a.out support in linux? A: Because a nasty coff is bad for your elf. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Vojtech P. <vo...@su...> - 2000-07-23 23:29:57
|
On Mon, Jul 24, 2000 at 01:18:56AM +0200, Franz Sirl wrote: > On Sun, 23 Jul 2000, Vojtech Pavlik wrote: > > On Sun, Jul 23, 2000 at 07:17:18PM +0200, Franz Sirl wrote: > > If you could also patch the attached list of scancodes with the added > > stuff, I'd be grateful ... > > Which attachment? Maybe you should checkin that to ruby :-). I forgot to attach it. Ok, it's in ruby, under utils/ > > > Appended a new patch, which does > > > it like you suggest. Mind you that I still didn't touch keycodes 179 and > > > 180 which seem to disagree between input.h and evtest.c (which says they > > > are KPLeftParenthesis and KPRightParenthesis). > > > > Added to input.h > > Thanks. I've got another report now on the USB KPComma key (0x85), is it safe > to map that to KEY_KPDOT, or do keyboards with both of them exist? I hope it's safe, I haven't seen a keyboard with both yet. > > I hope Linus will accept it. The split (drivers/usb + > > drivers/char/joystick) already is causing trouble. > > Any feedback from Linus yet? No, and I doubt there will be any - either the patch appears in some of the later kernels or not. > > Great. Well, you can send it even if it's not tested - ruby is a > > development tree, many things there don't event compile. > > OK, I have to make some decisions still, but after that I'll send it. Thanks. > > Thank you. You know, it really makes me happy hearing this. > > Well, that's the way I feel after working with the code. There are some minor > loose ends, but I really like the design. Yes, I believe it'll get better with time. -- Vojtech Pavlik SuSE Labs |
|
From: Franz S. <Fra...@la...> - 2000-07-23 23:22:00
|
On Sun, 23 Jul 2000, Vojtech Pavlik wrote: > On Sun, Jul 23, 2000 at 07:17:18PM +0200, Franz Sirl wrote: > If you could also patch the attached list of scancodes with the added > stuff, I'd be grateful ... Which attachment? Maybe you should checkin that to ruby :-). > > Appended a new patch, which does > > it like you suggest. Mind you that I still didn't touch keycodes 179 and > > 180 which seem to disagree between input.h and evtest.c (which says they > > are KPLeftParenthesis and KPRightParenthesis). > > Added to input.h Thanks. I've got another report now on the USB KPComma key (0x85), is it safe to map that to KEY_KPDOT, or do keyboards with both of them exist? > > Now I just have to pray to the Linux gods that Linus will accept the move > > of the input drivers into drivers/input in 2.4, so I can rely on them in > > the ADB HID driver even without CONFIG_USB defined. > > I hope Linus will accept it. The split (drivers/usb + > drivers/char/joystick) already is causing trouble. Any feedback from Linus yet? > > As soon that happens and I tested > > my code, I'll send you a clean adbhid.c for ruby. > > Great. Well, you can send it even if it's not tested - ruby is a > development tree, many things there don't event compile. OK, I have to make some decisions still, but after that I'll send it. > > I already said it and I say it again, I just _love_ the clean HID drivers > > possible with the input layer :-). > > Thank you. You know, it really makes me happy hearing this. Well, that's the way I feel after working with the code. There are some minor loose ends, but I really like the design. Franz. |
|
From: Vojtech P. <vo...@su...> - 2000-07-23 19:36:24
|
On Sun, Jul 23, 2000 at 07:17:18PM +0200, Franz Sirl wrote: > Well, it's ugly, but I can live with that. It is, but it'll allow existing mappings to keep working. There is a lot more ugliness in the numbering of the keys, so I think this is not a big problem. If you could also patch the attached list of scancodes with the added stuff, I'd be grateful ... > Appended a new patch, which does > it like you suggest. Mind you that I still didn't touch keycodes 179 and 180 > which seem to disagree between input.h and evtest.c (which says they are > KPLeftParenthesis and KPRightParenthesis). Added to input.h > I included the generic changes for Macintosh keycode support too. The > correction of the small plain_map/key_maps[0] uncleanliness in keyboard.c is > necessary to support dynamic switching between keymaps, which I need to > support both ADB and Linux keycodes at the same time. Ok. > OK, one roadblock removed now, I guess the changes in drivers/input and > input.h will be in 2.4 (and the backports) automatically with your merges? Yes, I hope so. As long as they don't break 2.4. > Now I just have to pray to the Linux gods that Linus will accept the move of > the input drivers into drivers/input in 2.4, so I can rely on them in the ADB > HID driver even without CONFIG_USB defined. I hope Linus will accept it. The split (drivers/usb + drivers/char/joystick) already is causing trouble. > As soon that happens and I tested > my code, I'll send you a clean adbhid.c for ruby. Great. Well, you can send it even if it's not tested - ruby is a development tree, many things there don't event compile. > I already said it and I say it again, I just _love_ the clean HID drivers > possible with the input layer :-). Thank you. You know, it really makes me happy hearing this. -- Vojtech Pavlik SuSE Labs |
|
From: Franz S. <Fra...@la...> - 2000-07-23 17:20:33
|
On Sun, 23 Jul 2000, Vojtech Pavlik wrote: > On Thu, Jul 20, 2000 at 04:07:52PM +0200, Franz Sirl wrote: > > Hi, > > > > I have a hard time thinking about a reasonable mapping for the 4 extra > > keys available on a Apple japanese USB and ADB keyboards (and this can > > only get worse as more asian keyboards layouts will be supported). The > > Apple version correctly uses international and language keys as defined > > in the HUT spec 1.1, one of them is currently already mapped to KEY_JPN > > in hid.c, but the others... > > > > So I suggest to add defines for KEY_INTL1-9 and KEY_LANG1-9 in input.h, > > with a comment that they should be used as specified in the HUT. This > > would in turn make KEY_JPN superfluous. > > I'd suggest KEY_INTL1 or KEY_LANG1 be the number KEY_JPN has now. What > do you think? Well, it's ugly, but I can live with that. Appended a new patch, which does it like you suggest. Mind you that I still didn't touch keycodes 179 and 180 which seem to disagree between input.h and evtest.c (which says they are KPLeftParenthesis and KPRightParenthesis). I included the generic changes for Macintosh keycode support too. The correction of the small plain_map/key_maps[0] uncleanliness in keyboard.c is necessary to support dynamic switching between keymaps, which I need to support both ADB and Linux keycodes at the same time. OK, one roadblock removed now, I guess the changes in drivers/input and input.h will be in 2.4 (and the backports) automatically with your merges? Now I just have to pray to the Linux gods that Linus will accept the move of the input drivers into drivers/input in 2.4, so I can rely on them in the ADB HID driver even without CONFIG_USB defined. As soon that happens and I tested my code, I'll send you a clean adbhid.c for ruby. I already said it and I say it again, I just _love_ the clean HID drivers possible with the input layer :-). Franz. |
|
From: Vojtech P. <vo...@su...> - 2000-07-23 08:45:53
|
On Sat, Jul 22, 2000 at 08:03:38PM -0400, James Simmons wrote: > > > /dev/input/eventmixX, based on the EV_STATUS messages and the rules in the > > > config file. That way most applications do not even need to know that this > > > can happen and can just keep on reading the FD. > > > My interest in here, I think it would be nice to attach more than one > > > device to a eventmixX device, eg. all mice or all keyboards (or both?), > > > similar to /dev/input/mice. That would make it a lot easier to port > > > applications to the input layer. > > > > I have never contributed to this list, but I have followed it regularly in > > the last 3 months and here's my 2p: applications should not know about > > all these low level connection stuff, I much prefer the idea of the > > userland deamon. > > That would be alot more complex than you think. The best thing to so is > set it up to send a EV_STATUS to the app and it can responded. This way > the app knows it no longer has the device. KISS. I agree here. Plus try to connect the device back if the app has it still open and the device appears again. (temporary disconnect on usb due to line noise). Send the app EV_STATUS, ST_CONNECT message in that case. -- Vojtech Pavlik SuSE Labs |
|
From: Mike A. H. <mh...@me...> - 2000-07-23 01:41:13
|
I've been trying to get ttysnoop to work with 2.2.x now for a couple weeks and am not getting anywhere. I don't really care if the program itself ever works, rather I want the following functionality out of ANY program in ANY way. 1) I want to be able to type: peekaboo <ttyX> where ttyX is *ANY* tty in the system, tty1, ttyp3, ttya4, /dev/pts/0, etc.. 2) I want the entire contents of the tty's screen to be mirrored to my own screen (assuming equal screen sizes). It would be nice if my keyboard is attached as well, or if there was a key sequence to connect/disconnect my keyboard. If no such program exists that actually WORKS and WORKS with a 2.2.x kernel, can someone help me create one? I'd like to do this standalone with no server if possible. My thinking is that, if the kernel controls tty's, then it should be possible via kernel syscalls to completely take over a tty via root, or via suid root app. similar to ttysnoop, but without having to have ttysnoopd intercepting as a middle man in inetd. ttysnoop doesn't work with ssh for example. So, how does one intercept tty's then? A combo userland app, kernel module would be fine, but I want a clean solution that doesn't require mucking with inetd configuration, or modifying other programs source code. Someone has suggested "screen" to me, and I know what screen is and does, and use it on a daily basis, and am familiar with the manpage and all options - it does not allow me to view someone ELSE's ssh session however. It doesn't in fact do anything that I want this for. So, please respond only with info on such a ttysnoop replacement in existance, or some advice on creating one in userland, in kernel, or combo of both. Thanks very much in advance! Take care! TTYL -- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate ... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4. |
1998 messages has been excluded from this view by a project administrator.
