Re: AllowEmptyInput and HAL (SOLVED!!!)
Finally solved, after something like 60 hours of hacking. My libX11.so was old. This caused xkbcomp to fail to parse the keymap files - it didn't recognise ISO_Level5 stuff. It looks like xkbcomp generated a keymap with some sort of Any+Any definition that caused every key to toggle the modifiers. This morning I attempted to purge and re-install all of my X-related Debian packages. I got rid of the server stuff but I couldn't get rid of the client libraries because that would cause huge numbers of client programs to be removed too. But I didn't worry about that because the problem was clearly on the server side. I eventually latched on to the level 5 warnings and started looking for them with strings. Then ldd on xkbcomp pointed at the guilty library. I'm surprised that it didn't work with the xserver that I built using khbuild. Presumably this is because that was still using libraries from /usr/lib, not the ones that it had just built and put somewhere in $HOME. Is that an rpath issue with khbuild? What can we learn? - Debian needs a more strongly-versioned dependency between some of its packages. I'll take that up with them (if the appropriate people are already reading this, please let me know). - xkbcomp, when called by the server, claims that xkbcomp errors are not fatal to the server. And only some of its messages appear in the X log file. I feel that this particular error should be considered fatal. And ideally, the consequence of an unrecognised keysym should not be the Any Key effect that I got. (Is the person responsible for xkbcomp reading this?). Thanks to those of you who helped with suggestions. Regards, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Peter Hutterer wrote:
On Wed, May 06, 2009 at 10:32:53PM +0100, Phil Endecott wrote:
(gdb) print xkbi-desc-server-acts[56]
$28 = {any = {type = 3 '\003', data = \000\001\000\000\001\000}, mods
= {type = 3 '\003', flags = 0 '\0',
mask = 1 '\001', real_mods = 0 '\0', vmods = 256}, group = {type =
3 '\003', flags = 0 '\0',
This is when I press 'a'. Note that mods.mask is 1; it should surely
be 0.
actions are things to be triggered when the matching key combo has been
pressed. the action you're looking at is to be triggered when shift is
down, but it does not describe the current state of the keyboard.
the current state is in dev-key-xkbInfo-desc-state, and the current
modifiers are a binary OR of the base/latched/locked_mods in that state
field.
Hi Peter,
(gdb) break XkbHandleActions
Breakpoint 1 at 0x8122487: file xkbActions.c, line 1072.
(gdb) cont
Continuing.
Breakpoint 1, XkbHandleActions (dev=0x82bf838, kbd=0x82bf838,
event=0x82c8268) at xkbActions.c:1072
1072{
(gdb) print dev-key-xkbInfo-desc-state
There is no member named state.
Maybe this is what you meant:
(gdb) print dev-key-xkbInfo.state
$4 = {group = 0 '\0', base_group = 0, latched_group = 0, locked_group =
0 '\0', mods = 0 '\0', base_mods = 0 '\0', latched_mods = 0 '\0',
locked_mods = 0 '\0',
compat_state = 0 '\0', grab_mods = 0 '\0', compat_grab_mods = 0 '\0',
lookup_mods = 0 '\0', compat_lookup_mods = 0 '\0', ptr_buttons = 0}
Here initially mods=0, but it changes:
(gdb) cont
Continuing.
Breakpoint 1, XkbHandleActions (dev=0x82bf838, kbd=0x82bf838,
event=0x82c8268) at xkbActions.c:1072
1072{
(gdb) print dev-key-xkbInfo.state
$7 = {group = 0 '\0', base_group = 0, latched_group = 0, locked_group =
0 '\0', mods = 5 '\005', base_mods = 5 '\005', latched_mods = 0 '\0',
locked_mods = 5 '\005',
compat_state = 5 '\005', grab_mods = 5 '\005', compat_grab_mods = 5
'\005', lookup_mods = 5 '\005', compat_lookup_mods = 5 '\005',
ptr_buttons = 0}
I see a pattern of mods=0 and mods=5 that's consistent with the
alternating pattern that I posted in the xev output previously.
I am wondering what I could have done to provoke this. I had a
~/.xmodmap that maps caps-lock to ctrl, but that is now disabled and I
was getting the same problem at the xdm login dialog and when root ran
startx. I also had changes to the console keymap stuff to get the same
effect, but I don't believe that the console keymap affects X (hence my
question before about where X gets the keymap from in a HAL
environment, i.e. does it somehow use the kernel keymap), and anyway
that console keymap hack stopped working after the same apt-get that
broke X.
And I'm still getting errors from xkbcomp, despite disabling my ~/.xmodmap.
Phil.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Phil Endecott wrote: Phil Endecott wrote: Phil Endecott wrote: Daniel Stone wrote: Hi, On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). Cool. Could you please send xev output? Unfortunately this is hard as I cannot log in. Presumably there is some way in which I can bypass xdm and cause X to start running and then start xev from another machine, or something. I'll investigate. I started x using startx and I can now retype the following xev output. This is for press-release-press-release of the A key. The pattern then repeats and seems to be consistent with other keys: KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372197, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) XmbLookupString gives 1 bytes: (01) XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372293, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372549, (78,77), root:(699,464), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) a XmbLookupString gives 1 bytes: (61) a XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372621, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) I've also tried to see what's going on using gdb. This isn't easy as the executables seem to be stripped. What I can see is that I get only the expected call per key up or down event through as far as mieqEnqueue(), so there can't be extra ctrl key events injected before that point. I then see four calls to ProcessOtherEvent() for one up-and-down, which I believe is perhaps due to the master and slave (I haven't tried to understand this). I think I will need to build a non-stripped version to get any further in this direction. Overnight I built a new not-stripped xserver using khbuild. This exhibits similar, but not identical, behaviour to the previous system. Before alternate keystrokes were sent as if ctrl was pressed [actually ctrl+shift I think; see state=0x5 above]. Now those keystrokes are sent as if shift is pressed, i.e. I see state=0x1 in the xev output. Running under gdb I now see this: Program received signal SIGTRAP, Trace/breakpoint trap. 0xb7c1f8c0 in realloc () from /lib/libc.so.6 (gdb) where #0 0xb7c1f8c0 in realloc () from /lib/libc.so.6 #1 0x080a6e12 in Xrealloc (ptr=0x82c96f0, amount=248) at utils.c:1127 #2 0x0809b282 in mieqProcessInputEvents () at mieq.c:398 #3 0x080be0c7 in ProcessInputEvents () at xf86Events.c:172 #4 0x080960cc in Dispatch () at dispatch.c:358 #5 0x0806394a in main (argc=5, argv=0xbfd63874, envp=0x0) at main.c:283 I guess this means that realloc thinks ptr=0x82c96f0 is not allocated or already-freed. Perhaps I should now try valgrind. Does any of this look familiar to anyone? It is taking me a very long time to understand this because I have never looked at any of this code before Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Phil Endecott wrote:
Phil Endecott wrote:
Phil Endecott wrote:
Phil Endecott wrote:
Daniel Stone wrote:
Hi,
On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote:
I have a keyboard
where every alternate keystroke produces the right letter and the
others produce garbage (maybe top-bit-set characters?).
Cool. Could you please send xev output?
Unfortunately this is hard as I cannot log in. Presumably there is
some way in which I can bypass xdm and cause X to start running and
then start xev from another machine, or something. I'll investigate.
I started x using startx and I can now retype the following xev
output. This is for press-release-press-release of the A key. The
pattern then repeats and seems to be consistent with other keys:
KeyPress event, serial 27, synthetic NO, window 0xa1,
root 0x3e, subw 0, time 7372197, (78,77), root:(699,464),
state 0x5, keycode 38 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (01)
XmbLookupString gives 1 bytes: (01)
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0xa1,
root 0x3e, subw 0, time 7372293, (78,77), root:(699,464),
state 0x5, keycode 38 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (01)
KeyPress event, serial 27, synthetic NO, window 0xa1,
root 0x3e, subw 0, time 7372549, (78,77), root:(699,464),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) a
XmbLookupString gives 1 bytes: (61) a
XFilterEvent returns: False
KeyRelease event, serial 27, synthetic NO, window 0xa1,
root 0x3e, subw 0, time 7372621, (78,77), root:(699,464),
state 0x5, keycode 38 (keysym 0x41, A), same_screen YES,
XLookupString gives 1 bytes: (01)
I've also tried to see what's going on using gdb. This isn't easy as
the executables seem to be stripped. What I can see is that I get only
the expected call per key up or down event through as far as
mieqEnqueue(), so there can't be extra ctrl key events injected before
that point. I then see four calls to ProcessOtherEvent() for one
up-and-down, which I believe is perhaps due to the master and slave
(I haven't tried to understand this). I think I will need to build a
non-stripped version to get any further in this direction.
Overnight I built a new not-stripped xserver using khbuild. This
exhibits similar, but not identical, behaviour to the previous system.
Before alternate keystrokes were sent as if ctrl was pressed [actually
ctrl+shift I think; see state=0x5 above]. Now those keystrokes are
sent as if shift is pressed, i.e. I see state=0x1 in the xev output.
Running under gdb I now see this:
Program received signal SIGTRAP, Trace/breakpoint trap.
0xb7c1f8c0 in realloc () from /lib/libc.so.6
(gdb) where
#0 0xb7c1f8c0 in realloc () from /lib/libc.so.6
#1 0x080a6e12 in Xrealloc (ptr=0x82c96f0, amount=248) at utils.c:1127
#2 0x0809b282 in mieqProcessInputEvents () at mieq.c:398
#3 0x080be0c7 in ProcessInputEvents () at xf86Events.c:172
#4 0x080960cc in Dispatch () at dispatch.c:358
#5 0x0806394a in main (argc=5, argv=0xbfd63874, envp=0x0) at main.c:283
I guess this means that realloc thinks ptr=0x82c96f0 is not allocated
or already-freed.
I now think this was spurious. On later runs I got the SIGTRAP
elsewhere. I think it might be an artifact of the X code changing
signal masks and the way gdb does breakpoints.
Perhaps I should now try valgrind.
Valgrind had nothing interesting to report.
I now think that the problem must be in the keymap:
(gdb) where
#0 XkbHandleActions (dev=0x82bf838, kbd=0x82bf838, event=0x83097a8) at
xkbActions.c:1183
#1 0x08118fc1 in XkbProcessKeyboardEvent (event=0x83097a8,
keybd=0x82bf838) at xkbPrKeyEv.c:159
#2 0x08106289 in AccessXFilterPressEvent (event=0x83097a8,
keybd=0x82bf838) at xkbAccessX.c:561
#3 0x08119373 in ProcessKeyboardEvent (ev=0x83097a8, keybd=0x82bf838)
at xkbPrKeyEv.c:195
#4 0x0809b08d in mieqProcessDeviceEvent (dev=0x82bf838,
event=0x83097a8, screen=0x8201650) at mieq.c:367
#5 0x0809b22f in mieqProcessInputEvents () at mieq.c:427
#6 0x080be0c7 in ProcessInputEvents () at xf86Events.c:172
#7 0x080960cc in Dispatch () at dispatch.c:358
#8 0x0806394a in main (argc=5, argv=0xbfb0d634, envp=0x82c1ed0) at main.c:283
(gdb) print event.detail
$24 = {button = 38, key = 38}
(gdb) print xkbi-desc-server-key_acts[38]
$25 = 56
(gdb) print xkbi-desc-server-acts[56]
$28 = {any = {type = 3 '\003', data = \000\001\000\000\001\000}, mods
= {type = 3 '\003', flags = 0 '\0',
mask = 1 '\001', real_mods = 0 '\0', vmods = 256}, group = {type =
3 '\003', flags = 0 '\0',
group_XXX = 1 '\001'}, iso = {type = 3 '\003', flags = 0 '\0', mask
= 1 '\001', real_mods = 0 '\0',
group_XXX = 0 '\0', affect = 1 '\001', vmods = 137109200}, ptr =
{type = 3 '\003', flags = 0 '\0', x
Re: AllowEmptyInput and HAL
Julien Cristau wrote: On Tue, May 5, 2009 at 18:58:21 +0100, Phil Endecott wrote: Still battling with this. Help! Some new details below. Do you run xmodmap to somehow change the keymap? Yes I have a ~/.xmodmap that will have been run in the startx case. However that would not have been run in the xdm case - I was seeing the same misbehaviour at the xdm login dialog. Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Daniel Stone wrote: Hi, On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: Specifically, when X started I had no keyboard or mouse. After power-cycling [no other way to escape!] I found a message in the log saying that AllowEmptyInput was enabled and that my keyboard and mouse configuration was being ignored. Having looked this up in man xorg.conf I see that this mode is the default. I'll try to be polite: This does not seem like the most useful behaviour. AllowEmptyInput does not mean that your keyboard and mouse configuration is being ignored; conversely, it means that it's not a fatal error to have no keyboard and mouse configuration whatsoever. So if AEI changes anything, you don't have a keyboard and mouse configured. Here is what it reported in the log: (WW) AllowEmptyInput is on, devices usingdrivers 'kbd, 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Generic Keyboard (WW) Disabling Evoluent Vertical Mouse That looks to me as if the default setting of that option causes X to ignore (or disable, if that means something different) my keyboard and mouse. Having set AutoAddDevices to false in order to disable the unhelpful AllowEmptyInput, I now have a functioning mouse. But I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). Cool. Could you please send xev output? Unfortunately this is hard as I cannot log in. Presumably there is some way in which I can bypass xdm and cause X to start running and then start xev from another machine, or something. I'll investigate. Looking at this some more, here is what I think is happening. This is based on what I type at the xdm username: prompt. Characters are alternately normal and sent with Ctrl. So e.g. h is backspace, j shows a glyph with a V above a T for vertical tab, etc. I also get box-drawing characters for some letters. I also noticed some messages in the log where config/hal complained that NewInputDeviceRequest failed. Presumably this is because of my AutoAddDevices. I had noticed that Debian installed hal; I had not previously heard of it. It looks like something that sits on top of udev. Yes, it is. NewInputDeviceRequest failing sounds like the evdev driver isn't installed. evdev was listed in the Modules section (I had been using it previously for the Powermate) and I don't recall any problems with it mentioned in the log. BTW, attaching complete logs instead of two-word snippets often leads to significantly more happiness. I would love to copy-and-paste the logs but I am sending this from another computer. The bit above was re-typed. So I've now spent most of three days on this. I just want a computer that works, preferably as well as the old one did, and while I don't have one I can't do much work [I'm self-employed]. So could someone please suggest what I should do: - Is there some simple set of xorg.conf settings that will make it just work like it did before, without any AllowEmptyInput and HAL stuff and with a functional keyboard? The Debian guys can explain that much better than me. - Or would I be better off trying to learn how this HAL thing works? X is something that I only have to understand once every few years when I have some new hardware. By the next time I need to understand it, either I have forgotten something vital or it has all changed Well, not upgrading guarantees there won't be any changes. :) I would have loved to not upgrade. There was nothing wrong with the old system until it broke. Paul Menzel suggests that I should be able to run with no Xorg.conf. When I try this I still get the bizarre keyboard behaviour. The Debian package versions are: xserver-xorg 7.4+1 xserver-xorg-core 1.6.1-1 xserver-xorg-input-evdev 2.2.1-1 xserver-xorg-input-kbd 1.3.2-3 xserver-input-mouse 1.4.0-2 xserver-xorg-input-synaptics 1.1.0-1 xserver-xorg-input-wacom 0.8.3.2-1 xserver-xorg-video-openchrome 0.2.903+svn741-1+b1 Regards, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: AllowEmptyInput and HAL
Phil Endecott wrote: Daniel Stone wrote: Hi, On Tue, Apr 28, 2009 at 10:01:25PM +0100, Phil Endecott wrote: I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). Cool. Could you please send xev output? Unfortunately this is hard as I cannot log in. Presumably there is some way in which I can bypass xdm and cause X to start running and then start xev from another machine, or something. I'll investigate. I started x using startx and I can now retype the following xev output. This is for press-release-press-release of the A key. The pattern then repeats and seems to be consistent with other keys: KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372197, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) XmbLookupString gives 1 bytes: (01) XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372293, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) KeyPress event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372549, (78,77), root:(699,464), state 0x0, keycode 38 (keysym 0x61, a), same_screen YES, XLookupString gives 1 bytes: (61) a XmbLookupString gives 1 bytes: (61) a XFilterEvent returns: False KeyRelease event, serial 27, synthetic NO, window 0xa1, root 0x3e, subw 0, time 7372621, (78,77), root:(699,464), state 0x5, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (01) I then ran strace on X and looked at what it read from /dev/input/event1 while I did the same thing. Deciphering using /usr/include/linux/input.h I see MSC SCAN 0407 KEY A DOWN SYN MSC SCAN 0407 KEY A UP SYN MSC SCAN 0407 KEY A DOWN SYN MSC SCAN 0407 KEY A UP SYN i.e. nothing unusual (I haven't seen the 'scan' stuff before, but I presume that X has done an ioctl to ask for it or something.) Perhaps these events are being misinterpretted in the wrong format, or something. But in that case I would have expected the symptom to be recognised by someone. Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
Peter Hutterer wrote: On Mon, Apr 27, 2009 at 12:09:17AM +0100, Phil Endecott wrote: Option DIALRelativeAxisButtons 4 5 This option isn't supported anymore. OK. I think something like this is needed, though. If you have an application that actually knows about the dial axis that's fine, but in most cases you'll want to do some sort of mapping. I don't see any mention of the mouse scroll wheel in the new evdev man page; how is that managed? The old driver was ugly (bitmasks etc) but useful. I hope the new version hasn't thrown the baby out with the bath water. As Dan said, the device doesn't advertise a known combination of axes + buttons. Please run http://people.freedesktop.org/~whot/evtest.c against the device file and attach the output to a bug on bugs.freedesktop.org. Here's the output, also filed as http://bugs.freedesktop.org/show_bug.cgi?id=21457 : Input driver version is 1.0.0 Input device ID: bus 0x3 vendor 0x77d product 0x410 version 0x400 Input device name: Griffin PowerMate Supported events: Event type 0 (Sync) Event type 1 (Key) Event code 256 (Btn0) Event type 2 (Relative) Event code 7 (Dial) Event type 4 (Misc) Event code 1 (Pulseled) Grab succeeded, ungrabbing. Testing ... (interrupt to exit) Event: time 1240909108.341856, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909108.341878, -- Report Sync Event: time 1240909108.773822, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909108.773838, -- Report Sync Event: time 1240909109.029820, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.029836, -- Report Sync Event: time 1240909109.149823, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.149839, -- Report Sync Event: time 1240909109.357821, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909109.357837, -- Report Sync Event: time 1240909109.445820, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.445837, -- Report Sync Event: time 1240909109.509826, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.509843, -- Report Sync Event: time 1240909109.565820, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.565836, -- Report Sync Event: time 1240909109.629825, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.629841, -- Report Sync Event: time 1240909110.213829, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.213844, -- Report Sync Event: time 1240909110.253823, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.253839, -- Report Sync Event: time 1240909110.309823, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.309839, -- Report Sync Event: time 1240909110.381825, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.381842, -- Report Sync Event: time 1240909110.485828, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.485845, -- Report Sync Event: time 1240909110.573827, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.573842, -- Report Sync Event: time 1240909110.653830, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909110.653847, -- Report Sync Event: time 1240909112.125830, type 1 (Key), code 256 (Btn0), value 1 Event: time 1240909112.125847, -- Report Sync Event: time 1240909112.381823, type 1 (Key), code 256 (Btn0), value 0 Event: time 1240909112.381838, -- Report Sync Event: time 1240909112.789830, type 2 (Relative), code 7 (Dial), value 1 Event: time 1240909112.789845, -- Report Sync Event: time 1240909112.893831, type 1 (Key), code 256 (Btn0), value 1 Event: time 1240909112.893848, -- Report Sync Event: time 1240909113.141823, type 1 (Key), code 256 (Btn0), value 0 Event: time 1240909113.141838, -- Report Sync Thanks, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
Dan Nicholson wrote: On Tue, Apr 28, 2009 at 2:33 AM, Phil Endecott spam_from_x...@chezphil.org wrote: Peter Hutterer wrote: On Mon, Apr 27, 2009 at 12:09:17AM +0100, Phil Endecott wrote:    Option      DIALRelativeAxisButtons 4 5 This option isn't supported anymore. OK.  I think something like this is needed, though.  If you have an application that actually knows about the dial axis that's fine, but in most cases you'll want to do some sort of mapping.  I don't see any mention of the mouse scroll wheel in the new evdev man page; how is that managed? Read the description for EmulateWheel in evdev(4). Ah OK - I don't have that in my (Debian packaged) man evdev, so I guess it's a recent addition. My man page claims to be version 2.0.8. EmulateWheel is what I have for my real mouse so it should do what I need. (I do sometimes wonder whether more apps now work with a non-emulated wheel; when I scroll Firefox with my emulated wheel (or the Powermate on the old machine) it would take ages to catch up. I should try it. Maybe I need some hack so that some apps see the emulated events and others see axis events.) Event: time 1240909109.149823, type 2 (Relative), code 7 (Dial), value -1 Event: time 1240909109.149839, -- Report Sync Event: time 1240909109.357821, type 2 (Relative), code 7 (Dial), value 1 Is -1 turning the dial to the left and +1 turning the dial to the right? Yes. Cheers, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
AllowEmptyInput and HAL
Hello again, My efforts to recover from a dead computer continue. I have resurrected the old disk in a new box, but the new box has a different graphics chip and installing the (Debian packaged) driver for that has brought in new bits of everything, and it has all gone bad. Specifically, when X started I had no keyboard or mouse. After power-cycling [no other way to escape!] I found a message in the log saying that AllowEmptyInput was enabled and that my keyboard and mouse configuration was being ignored. Having looked this up in man xorg.conf I see that this mode is the default. I'll try to be polite: This does not seem like the most useful behaviour. Having set AutoAddDevices to false in order to disable the unhelpful AllowEmptyInput, I now have a functioning mouse. But I have a keyboard where every alternate keystroke produces the right letter and the others produce garbage (maybe top-bit-set characters?). I also noticed some messages in the log where config/hal complained that NewInputDeviceRequest failed. Presumably this is because of my AutoAddDevices. I had noticed that Debian installed hal; I had not previously heard of it. It looks like something that sits on top of udev. So I've now spent most of three days on this. I just want a computer that works, preferably as well as the old one did, and while I don't have one I can't do much work [I'm self-employed]. So could someone please suggest what I should do: - Is there some simple set of xorg.conf settings that will make it just work like it did before, without any AllowEmptyInput and HAL stuff and with a functional keyboard? - Or would I be better off trying to learn how this HAL thing works? X is something that I only have to understand once every few years when I have some new hardware. By the next time I need to understand it, either I have forgotten something vital or it has all changed Cheers, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Griffin Powermate evdev setup
Dan Nicholson wrote: On Sun, Apr 26, 2009 at 4:09 PM, Phil Endecott spam_from_x...@chezphil.org wrote: I have a Griffin Powermate; it's a USB knob that you can use for scrolling etc. ÃÂ This morning the computer that it was attached to died. ÃÂ I'm now having trouble getting to work with the substitute machine. (**) Griffin Powermate: always reports core events (**) Griffin Powermate: Device: /dev/input/by-id/usb-Griffin_Technology__Inc._Griffin_PowerMate-event-misc (WW) Griffin Powermate: Don't know how to use device (II) UnloadModule: evdev (EE) PreInit returned NULL for Griffin Powermate So, what does Don't know how to use device mean? This means that the evdev driver didn't recognize it to be either a pointer, a keyboard or a touchscreen during it's probing routine. Looking at a photo online, I can't really tell how you'd classify it, but there could certainly be bugs in the detection logic. If you have the source, take a look in src/evdev.c:EvdevProbe. http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/tree/src/evdev.c - Right? This seems like a regression since the previous version of this driver, which was able to manage this device. What can be done? (BTW the kernel driver is here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/input/misc/powermate.c) Cheers, Phil. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
