Menu
▾
▴
linuxconsole-dev
|
From: Ruben F. <par...@gm...> - 2006-01-26 10:57:02
|
About your evdev problem: I had the same problem. The large problem is the evdev keyboard driver not outputting the same keycodes as the kbd driver. As such, some keycodes which are assigned do not exist, whereas some are wrongly assigned. For now, this workaround helps: https://bugs.freedesktop.org/show_bug.cgi?id=5559 The bug has been assigned to the input/evdev developers, but I haven't heard from it ever since, so I guess it's low priority for them. Also, they probably should clean op Xkb-support for evdev first anyway, the current implementation is a hack IIRC. Good luck using this workaround. It's strange, without Xkb everything works correctly (with a qwerty layout). Could you tell me if it worked or add a comment on the bug page? Thanks. |
|
From: Mikhail K. <kl...@la...> - 2006-01-26 22:53:29
|
Hi Peter, > I've installed the new Debian Xorg 6.9 packages. They dropped the > proprietary support for evdev and implemented a clean evdev module (which is > a good news). But actually I can't get my keyboard working any more with this > new driver. It seems that the evdev driver doesn't support the XkbLayout > option of Xorg. > > Any ideas? you'll need to patch your evdev module. see https://bugs.freedesktop.org/show_bug.cgi?id=3912 for details cheers, Mikhail Kshevetskiy |
|
From: Zephaniah E. H. <wa...@ae...> - 2006-01-26 12:49:43
|
On Thu, Jan 26, 2006 at 11:56:47AM +0100, Ruben Faelens wrote: > About your evdev problem: > > I had the same problem. The large problem is the evdev keyboard driver > not outputting the same keycodes as the kbd driver. As such, some > keycodes which are assigned do not exist, whereas some are wrongly > assigned. For now, this workaround helps: > https://bugs.freedesktop.org/show_bug.cgi?id=5559 > > The bug has been assigned to the input/evdev developers, but I haven't > heard from it ever since, so I guess it's low priority for them. Also, > they probably should clean op Xkb-support for evdev first anyway, the > current implementation is a hack IIRC. > > Good luck using this workaround. It's strange, without Xkb everything > works correctly (with a qwerty layout). > > Could you tell me if it worked or add a comment on the bug page? Thanks. Could you take a look at https://bugs.freedesktop.org/show_bug.cgi?id=5696? In theory the enhanced xkb support should work quite a bit better. (It also needs additional testing.) -- 1024D/E65A7801 Zephaniah E. Hull <wa...@ae...> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. "<green>From</yellow>" "Wow. The green word From is no longer yellow. That's deep, man." -- Marcus Meissner & Lars Balker Rasmussen in the Scary Devil Monastery |
|
From: Aivils S. <ai...@un...> - 2006-01-26 14:17:31
|
On Ceturtdiena, 26. Janv=E2ris 2006 14:49, Zephaniah E. Hull wrote: > On Thu, Jan 26, 2006 at 11:56:47AM +0100, Ruben Faelens wrote: > > About your evdev problem: > > > > I had the same problem. The large problem is the evdev keyboard driver > > not outputting the same keycodes as the kbd driver. As such, some > > keycodes which are assigned do not exist, whereas some are wrongly > > assigned. For now, this workaround helps: > > https://bugs.freedesktop.org/show_bug.cgi?id=3D5559 > > > > The bug has been assigned to the input/evdev developers, but I haven't > > heard from it ever since, so I guess it's low priority for them. Also, > > they probably should clean op Xkb-support for evdev first anyway, the > > current implementation is a hack IIRC. > > > > Good luck using this workaround. It's strange, without Xkb everything > > works correctly (with a qwerty layout). > > > > Could you tell me if it worked or add a comment on the bug page? Thanks. > > Could you take a look at https://bugs.freedesktop.org/show_bug.cgi?id=3D5= 696? > > In theory the enhanced xkb support should work quite a bit better. > (It also needs additional testing.) More consrevative C compilator support patch: =2D-- evdev_rel.c.orig 2006-01-26 15:08:57.000000000 +0200 +++ evdev_rel.c 2006-01-26 16:07:33.000000000 +0200 @@ -68,24 +68,24 @@ static struct { const char *name; const int i; =2D} axis_names =3D { =2D "X", REL_X, =2D "Y", REL_Y, =2D "Z", REL_Z, =2D "RX", REL_RX, =2D "RY", REL_RY, =2D "RZ", REL_RZ, =2D "HWHEEL", REL_HWHEEL, =2D "DIAL", REL_DIAL, =2D "WHEEL", REL_WHEEL, =2D "MISC", REL_MISC, =2D "10", 10, =2D "11", 11, =2D "12", 12, =2D "13", 13, =2D "14", 14, =2D "15", 15, =2D NULL, 0 +} axis_names[] =3D { + {"X", REL_X}, + {"Y", REL_Y}, + {"Z", REL_Z}, + {"RX", REL_RX}, + {"RY", REL_RY}, + {"RZ", REL_RZ}, + {"HWHEEL", REL_HWHEEL}, + {"DIAL", REL_DIAL}, + {"WHEEL", REL_WHEEL}, + {"MISC", REL_MISC}, + {"10", 10}, + {"11", 11}, + {"12", 12}, + {"13", 13}, + {"14", 14}, + {"15", 15}, + {NULL, 0} }; =20 static void |
|
From: Peter S. <pet...@gm...> - 2006-01-26 21:09:33
|
Yop, that seems to work. I'm useing setxkbmap de -keycodes 'xfree86+aliases(qwertz)+aliases(evdev)' -option but my up/down keys are a mess. Pressing them sometimes causes a 100% CPU load (Xorg and kwin). But this happens only on console :0 with a ps/2 keyboard and only with the extra cursor keys (not those on the numpad). On console :2 (usb) it runs smoothly, everything's fine. Tell me if I can provide you with some debug info. Sorry, avilis. I don't have a X build system installed here and (if debian helps me) never will so I can't test the patches. But thanks anyway. Peter Ruben Faelens schrieb: > About your evdev problem: > > I had the same problem. The large problem is the evdev keyboard driver > not outputting the same keycodes as the kbd driver. As such, some > keycodes which are assigned do not exist, whereas some are wrongly > assigned. For now, this workaround helps: > https://bugs.freedesktop.org/show_bug.cgi?id=5559 > > The bug has been assigned to the input/evdev developers, but I haven't > heard from it ever since, so I guess it's low priority for them. Also, > they probably should clean op Xkb-support for evdev first anyway, the > current implementation is a hack IIRC. > > Good luck using this workaround. It's strange, without Xkb everything > works correctly (with a qwerty layout). > > Could you tell me if it worked or add a comment on the bug page? Thanks. > > > |
|
From: Aivils S. <ai...@un...> - 2006-01-27 07:28:17
|
On Ceturtdiena, 26. Janv=E2ris 2006 23:09, Peter Schrammel wrote: > Yop, that seems to work. I'm useing > setxkbmap de -keycodes 'xfree86+aliases(qwertz)+aliases(evdev)' -option > > but my up/down keys are a mess. Pressing them sometimes causes a 100% > CPU load (Xorg and kwin). But this happens only on console :0 with a > ps/2 keyboard and only with the extra cursor keys (not those on the > numpad). > > On console :2 (usb) it runs smoothly, everything's fine. > > Tell me if I can provide you with some debug info. > > Sorry, avilis. I don't have a X build system installed here and (if > debian helps me) never will so I can't test the patches. But thanks anywa= y. If You are not fanatic compile-from-scratch sympatizer, then You can try out this one: http://www.ltn.lv/~aivils/files/evdev-zeh-060127.tar.bz2 Must have X server sources. Edit SERVER_SRC line in the Makefile Aivils |
|
From: Zephaniah E. H. <wa...@ae...> - 2006-01-28 02:11:48
|
On Fri, Jan 27, 2006 at 09:32:20AM +0200, Aivils Stoss wrote: > On Ceturtdiena, 26. Janv=C4=81ris 2006 23:09, Peter Schrammel wrote: > > Yop, that seems to work. I'm useing > > setxkbmap de -keycodes 'xfree86+aliases(qwertz)+aliases(evdev)' -option > > > > but my up/down keys are a mess. Pressing them sometimes causes a 100% > > CPU load (Xorg and kwin). But this happens only on console :0 with a > > ps/2 keyboard and only with the extra cursor keys (not those on the > > numpad). > > > > On console :2 (usb) it runs smoothly, everything's fine. > > > > Tell me if I can provide you with some debug info. > > > > Sorry, avilis. I don't have a X build system installed here and (if > > debian helps me) never will so I can't test the patches. But thanks any= way. >=20 > If You are not fanatic compile-from-scratch sympatizer, then You can try = out > this one: > http://www.ltn.lv/~aivils/files/evdev-zeh-060127.tar.bz2 >=20 > Must have X server sources. Edit SERVER_SRC line in the Makefile >=20 > Aivils Thanks a ton for putting that together. However there's been a slight bug fix patch update which helps compiling with some compilers. If you'd like I can generate a diff between that version and current? Zephaniah E. Hull. --=20 1024D/E65A7801 Zephaniah E. Hull <wa...@ae...> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Here's your cable. We made it fifty feet long, just in case. In case what, in case tectonic movement makes the serial ports farther apart? -- Carl Jacobs on ASR. |
|
From: Aivils S. <ai...@un...> - 2006-01-31 09:34:33
|
On Sestdiena, 28. Janv=E2ris 2006 04:11, Zephaniah E. Hull wrote: > On Fri, Jan 27, 2006 at 09:32:20AM +0200, Aivils Stoss wrote: > > On Ceturtdiena, 26. Janv=E2ris 2006 23:09, Peter Schrammel wrote: > > > Yop, that seems to work. I'm useing > > > setxkbmap de -keycodes 'xfree86+aliases(qwertz)+aliases(evdev)' -opti= on > > > > > > but my up/down keys are a mess. Pressing them sometimes causes a 100% > > > CPU load (Xorg and kwin). But this happens only on console :0 with a > > > ps/2 keyboard and only with the extra cursor keys (not those on the > > > numpad). > > > > > > On console :2 (usb) it runs smoothly, everything's fine. > > > > > > Tell me if I can provide you with some debug info. > > > > > > Sorry, avilis. I don't have a X build system installed here and (if > > > debian helps me) never will so I can't test the patches. But thanks > > > anyway. > > > > If You are not fanatic compile-from-scratch sympatizer, then You can try > > out this one: > > http://www.ltn.lv/~aivils/files/evdev-zeh-060127.tar.bz2 > > > > Must have X server sources. Edit SERVER_SRC line in the Makefile > > > > Aivils > > Thanks a ton for putting that together. > > However there's been a slight bug fix patch update which helps > compiling with some compilers. > > If you'd like I can generate a diff between that version and current? I download new version. It contains old bug: EvdevReadInput() may call EvdevRelSyn() on EV_SYN, but for keyboards relative stuff is=20 uninitialised - segfault. Of course driver must be capable hadle keys and axis events together from tablet devices, which have keys, absolute and relative axis and buttons too. Also one version before latest will not work proper if i create/delete devices in the runtime. It is not official but i provide this one: http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2 This package contains xmodule, which allow load/remove X server modules and xdevice, which allow create/delete X server input devices at runtime. Existing input drivers are compatible with xdevice, but Your not. Even xdevice never goes into main it make life easy during development. You don't need server restart on new driver version or on device parameter change. Fatal errors still are fatal. Syntaxis like this: # xmodule -l evdev # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1 You driver changes device indentifier unwarranted. You must search new device # xsetpointer -l normal device delete uses same identifier # xdevice -d e1 Aivils |
|
From: Zephaniah E. H. <wa...@ae...> - 2006-01-31 20:20:03
|
On Tue, Jan 31, 2006 at 11:38:39AM +0200, Aivils Stoss wrote: > I download new version. It contains old bug: EvdevReadInput() may > call EvdevRelSyn() on EV_SYN, but for keyboards relative stuff is > uninitialised - segfault. Of course driver must be capable hadle > keys and axis events together from tablet devices, which have keys, > absolute and relative axis and buttons too. Ah, easily fixed, I'll post a new patch sometime today. (Though possibly not before I run out the door.) > > Also one version before latest will not work proper if i create/delete > devices in the runtime. It is not official but i provide this one: > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2 > This package contains xmodule, which allow load/remove X server > modules and xdevice, which allow create/delete X server input devices > at runtime. Existing input drivers are compatible with xdevice, > but Your not. Even xdevice never goes into main it make life easy > during development. You don't need server restart on new driver > version or on device parameter change. Fatal errors still are fatal. > Syntaxis like this: > # xmodule -l evdev > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1 > You driver changes device indentifier unwarranted. You must search new > device > # xsetpointer -l > normal device delete uses same identifier > # xdevice -d e1 That looks handy, however due to hotplug support my driver is going to cause, interesting issues. Mainly, we create new driver instances for additional devices that are plugged in that match the specification for current devices. Because we need the new entries to be uniquely identifiable, we append the phys to the name. At this time there is no way around this. Also at the moment I'm not using a modular tree, which makes using that a bit harder even for testing purposes. Thanks. -- 1024D/E65A7801 Zephaniah E. Hull <wa...@ae...> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. >> kinds of numbers the tobacco industry wishes it had, and Dell is very >> very happy with the results. > >Do they come with a Surgeon General warning on the box? The new ones have "Designed for Windows XP". Yes. -- Satya, Paul Martin, and Derek Balling in the Scary Devil Monastery. |
|
From: Aivils S. <ai...@un...> - 2006-02-01 07:30:13
|
On Otrdiena, 31. Janv=E2ris 2006 22:19, Zephaniah E. Hull wrote: > > Also one version before latest will not work proper if i create/delete > > devices in the runtime. It is not official but i provide this one: > > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2 > > This package contains xmodule, which allow load/remove X server > > modules and xdevice, which allow create/delete X server input devices > > at runtime. Existing input drivers are compatible with xdevice, > > but Your not. Even xdevice never goes into main it make life easy > > during development. You don't need server restart on new driver > > version or on device parameter change. Fatal errors still are fatal. > > Syntaxis like this: > > # xmodule -l evdev > > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1 > > You driver changes device indentifier unwarranted. You must search new > > device > > # xsetpointer -l > > normal device delete uses same identifier > > # xdevice -d e1 > > That looks handy, however due to hotplug support my driver is going to > cause, interesting issues. > > Mainly, we create new driver instances for additional devices that are > plugged in that match the specification for current devices. > > Because we need the new entries to be uniquely identifiable, we append > the phys to the name. > > At this time there is no way around this. > > Also at the moment I'm not using a modular tree, which makes using that > a bit harder even for testing purposes. That package didn't use compile form scratch. All what You need is X server source for headers, runing X binary for some variables, gcc, X server resta= rt is necessary. I use it under my 6.8.2. xdevice was developed keeping in mind buch of all input devices. It does "hotplug" in large-scale without touching driver source. Seems SIGHUP is sacred. Even aiptek tablet developers did not replay. =46rom my point of view looks very stupid - plug new input device and then restart X for new config. Aivils |
|
From: Zephaniah E. H. <wa...@ae...> - 2006-02-01 14:57:37
|
On Wed, Feb 01, 2006 at 09:34:20AM +0200, Aivils Stoss wrote: > On Otrdiena, 31. Janv=C4=81ris 2006 22:19, Zephaniah E. Hull wrote: > > > Also one version before latest will not work proper if i create/delete > > > devices in the runtime. It is not official but i provide this one: > > > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2 > > > This package contains xmodule, which allow load/remove X server > > > modules and xdevice, which allow create/delete X server input devices > > > at runtime. Existing input drivers are compatible with xdevice, > > > but Your not. Even xdevice never goes into main it make life easy > > > during development. You don't need server restart on new driver > > > version or on device parameter change. Fatal errors still are fatal. > > > Syntaxis like this: > > > # xmodule -l evdev > > > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1 > > > You driver changes device indentifier unwarranted. You must search new > > > device > > > # xsetpointer -l > > > normal device delete uses same identifier > > > # xdevice -d e1 > > > > That looks handy, however due to hotplug support my driver is going to > > cause, interesting issues. > > > > Mainly, we create new driver instances for additional devices that are > > plugged in that match the specification for current devices. > > > > Because we need the new entries to be uniquely identifiable, we append > > the phys to the name. > > > > At this time there is no way around this. > > > > Also at the moment I'm not using a modular tree, which makes using that > > a bit harder even for testing purposes. >=20 > That package didn't use compile form scratch. All what You need is X serv= er > source for headers, runing X binary for some variables, gcc, X server res= tart > is necessary. I use it under my 6.8.2. >=20 > xdevice was developed keeping in mind buch of all input devices. It does > "hotplug" in large-scale without touching driver source. > Seems SIGHUP is sacred. Even aiptek tablet developers did not replay. > From my point of view looks very stupid - plug new input device and then > restart X for new config. After taking a closer look at it, it's a nice idea, but I'd suggest sitting down and considering the design and all implications for a while. Among other things, the kernel ioctl interface is a rather poor one to emulate, while at first glance it looks fairly easy to deal with, it has some noticeable scale issues as far as maintance goes. Take a look at some of the protocol discussions in the X.org wiki on the Hotplug subject, and keep trying. (The evdev driver is nowhere even close to being the first, second, or probably even eighth design for it that I actually wrote the code for, never mind that I've had. And it still has some design issues that I need to fix.) Zephaniah E. Hull. (Spelling not guaranteed this time around, I'm tired and going to bed.) --=20 1024D/E65A7801 Zephaniah E. Hull <wa...@ae...> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. <nonlinear> .net is microsofts perverted version of a java networked environment uglified for windows-specific crap -- nonlinear in #opengl |
|
From: Aivils S. <ai...@un...> - 2006-02-02 07:13:49
|
On Tre=F0diena, 1. Febru=E2ris 2006 16:57, Zephaniah E. Hull wrote: > On Wed, Feb 01, 2006 at 09:34:20AM +0200, Aivils Stoss wrote: > > On Otrdiena, 31. Janv=E2ris 2006 22:19, Zephaniah E. Hull wrote: > > > > Also one version before latest will not work proper if i > > > > create/delete devices in the runtime. It is not official but i > > > > provide this one: > > > > http://www.ltn.lv/~aivils/files/xentity-0.01.tar.bz2 > > > > This package contains xmodule, which allow load/remove X server > > > > modules and xdevice, which allow create/delete X server input devic= es > > > > at runtime. Existing input drivers are compatible with xdevice, > > > > but Your not. Even xdevice never goes into main it make life easy > > > > during development. You don't need server restart on new driver > > > > version or on device parameter change. Fatal errors still are fatal. > > > > Syntaxis like this: > > > > # xmodule -l evdev > > > > # xdevice -c e1,evdev,Phys,isa0060/serio0/input0,AlwaysCore,1 > > > > You driver changes device indentifier unwarranted. You must search > > > > new device > > > > # xsetpointer -l > > > > normal device delete uses same identifier > > > > # xdevice -d e1 > > > > > > That looks handy, however due to hotplug support my driver is going to > > > cause, interesting issues. > > > > > > Mainly, we create new driver instances for additional devices that are > > > plugged in that match the specification for current devices. > > > > > > Because we need the new entries to be uniquely identifiable, we append > > > the phys to the name. > > > > > > At this time there is no way around this. > > > > > > Also at the moment I'm not using a modular tree, which makes using th= at > > > a bit harder even for testing purposes. > > > > That package didn't use compile form scratch. All what You need is X > > server source for headers, runing X binary for some variables, gcc, X > > server restart is necessary. I use it under my 6.8.2. > > > > xdevice was developed keeping in mind buch of all input devices. It does > > "hotplug" in large-scale without touching driver source. > > Seems SIGHUP is sacred. Even aiptek tablet developers did not replay. > > From my point of view looks very stupid - plug new input device and then > > restart X for new config. > > After taking a closer look at it, it's a nice idea, but I'd suggest > sitting down and considering the design and all implications for a > while. > > Among other things, the kernel ioctl interface is a rather poor one to > emulate, while at first glance it looks fairly easy to deal with, it has > some noticeable scale issues as far as maintance goes. I think poor thing is writing 24 indentical requests instead one. May be i change my mind sometimes. > Take a look at some of the protocol discussions in the X.org wiki on the > Hotplug subject, and keep trying. I have troubles. It's ready. > (The evdev driver is nowhere even close to being the first, second, or > probably even eighth design for it that I actually wrote the code for, > never mind that I've had. And it still has some design issues that I > need to fix.) > > Zephaniah E. Hull. > (Spelling not guaranteed this time around, I'm tired and going to bed.) Aivils |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X