Bug#442316: Xorg hotplugging problems
Julien Cristau <[EMAIL PROTECTED]> writes: > Then it's a totally different issue, please don't mix them. Hm? AFAICT from reviewing the bug log, it's a longstanding issue that users simply didn't notice (for the most part) until hal briefly attempted to make everyone's keyboard use the evdev driver. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems
On Sat, Oct 27, 2007 at 17:20:57 -0400, Jack Dodds wrote: > If I understand this report, this bug is being treated as if it was > introduced in the evdev version in experimental. > > However, I am experiencing it with stable (etch). > Then it's a totally different issue, please don't mix them. Cheers, Julien
Bug#442316: [Pkg-utopia-maintainers] Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Thu, Oct 25, 2007 at 02:08:19AM +0200, Michael Biebl wrote: > David Nusinow schrieb: > > Ok, I missed that somehow. So it should probably be hal that generates this > > and not the xserver? > > The problem with hal generating the fdi file, would be that it could get > out of sync, whenever you run dpkg-reconfigure xserver-xorg. > We would also have to duplicate a lot of logic from xserver-xorgs > postinst in hal. Generating the fdi file from within xserver-xorg seems > to be more straightforward to me. > > If you are going to remove the input device section (generation) > completely from xserver-xorgs postinst and rely completely on hal for > that, then I agree hal should be the one and only place where to > configure the keyboard/input. > Doing the configuration at two places (xserver-xorg->xorg.conf and hal-> > fdi) will really cause headaches imho. Yeah, we'll remove it from the xserver postinst. The only thing I want is to allow the server to respect currently existing xorg.confs. So long as that happens, it's probably better if hal does create the fdi. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems
If I understand this report, this bug is being treated as if it was
introduced in the evdev version in experimental.
However, I am experiencing it with stable (etch).
I am running etch with Gnome. I have a two seat system (two independent
keyboards, mice, and screens). In etch, the two seat system can be set
up without patching anything, but it is essential to use evdev to do so.
I have two 104 key keyboards, the main one connected via a PS2 port, the
secondary one via USB.
The keyboard mappings are messed up. Both keyboards behave the same
way. For example, the key in the editing section of the keyboard
behaves like the key. The right key and the in
the keypad both cause a page down, but the key in the
editing section of the keyboard does nothing.
I would be very grateful for any suggestions for a workaround that could
be used in etch.
(BTW, The two seat system was previously running under sarge, without
this bug, but required patches to XFree86 and the kernel.)
Here's the keyboard setup.
Section "InputDevice"
Identifier"First Keyboard"
Driver"evdev"
Option"Device""/dev/input/event0"
Option"XkbRules""xorg"
Option"XkbModel""evdev"
Option"XkbLayout""us"
EndSection
Section "InputDevice"
Identifier"Second Keyboard"
Driver"evdev"
Option"Device""/dev/input/event1"
Option"XkbRules""xorg"
Option"XkbModel""evdev"
Option"XkbLayout""us"
EndSection
Here's the tail end of /var/log/Xorg.0.log
(II) evdev brain: Rescanning devices (1).
(**) Option "CoreKeyboard"
(**) Keyboard2-usb-:00:1d.1-1.1/input0: Core Keyboard
(**) Option "XkbRules" "xorg"
(**) Option "XkbModel" "pc104"
(**) Option "XkbLayout" "us"
(**) Option "Protocol" "ImPS/2"
(**) Mouse2: Device: "/dev/input/mouse1"
(**) Mouse2: Protocol: "ImPS/2"
(**) Option "CorePointer"
(**) Mouse2: Core Pointer
(**) Option "Device" "/dev/input/mouse1"
(**) Option "Emulate3Buttons" "true"
(**) Mouse2: Emulate3Buttons, Emulate3Timeout: 50
(**) Mouse2: ZAxisMapping: buttons 4 and 5
(**) Mouse2: Buttons: 9
(II) XINPUT: Adding extended input device "Mouse2" (type: MOUSE)
(II) XINPUT: Adding extended input device
"Keyboard2-usb-:00:1d.1-1.1/input0" (type: KEYBOARD)
(II) XINPUT: Adding extended input device "evdev brain" (type: evdev brain)
xkb_keycodes { include "xfree86+aliases(qwerty)" };
xkb_types{ include "complete" };
xkb_compatibility{ include "complete" };
xkb_symbols { include "pc(pc105)+us" };
xkb_geometry { include "pc(pc104)" };
(II) Keyboard2-usb-:00:1d.1-1.1/input0: Init
(II) evdev brain: Rescanning devices (2).
(II) Keyboard2-usb-:00:1d.1-1.1/input0: On
(II) Mouse2: ps2EnableDataReporting: succeeded
--
=
This email is digitally signed using the Enigmail
and GnuPG packages (http://enigmail.mozdev.org),
which can also be used by the recipient to verify
the digital signature.
=
signature.asc
Description: OpenPGP digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 07:55:35PM -0400, ext David Nusinow wrote: > On Wed, Oct 24, 2007 at 01:53:40PM +0300, Daniel Stone wrote: > > As I've said before, the X server isn't the only user of the field. :) > > Ubuntu were trying to move to cxkb a year or so ago, and the only thing > > that stopped them in the end was how huge the XKB codebase was, which > > I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets > > us finaly unify console and X keymaps ... > > Ok, I missed that somehow. So it should probably be hal that generates this > and not the xserver? Yep. > > Well, you could even have a postinst that scans xorg.conf and generates > > the FDI, but yes, the X server should be responsible for checking this > > and not breaking existing setups. > > Yeah, I'm mainly concerned with not breaking existing setups. I feel like > we've been doing that a lot lately. Luckly, lenny is a ways away so we have > time to break things quite a bit before we get it right. Sweet. Well, I'll happily take patches. Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: [Pkg-utopia-maintainers] Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
David Nusinow schrieb: > On Wed, Oct 24, 2007 at 01:53:40PM +0300, Daniel Stone wrote: >> On Tue, Oct 23, 2007 at 08:17:10PM -0400, ext David Nusinow wrote: >>> On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > layout is used. Yes, this should probably be fixed up, I guess. But the long-term fix is to provide an FDI file in /etc that specifies the keyboard layout. >>> My feeling is the other way around, provided that the X server is the only >>> user of this field. People already know how to edit xorg.conf, and they >>> expect it. Telling them to edit a relatively obscure file among many other >>> fdi's is more painful. There's also userspace tools that exist to help with >>> generating a xorg.conf, but nothing friendly to deal with fdi's. >> As I've said before, the X server isn't the only user of the field. :) >> Ubuntu were trying to move to cxkb a year or so ago, and the only thing >> that stopped them in the end was how huge the XKB codebase was, which >> I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets >> us finaly unify console and X keymaps ... > > Ok, I missed that somehow. So it should probably be hal that generates this > and not the xserver? The problem with hal generating the fdi file, would be that it could get out of sync, whenever you run dpkg-reconfigure xserver-xorg. We would also have to duplicate a lot of logic from xserver-xorgs postinst in hal. Generating the fdi file from within xserver-xorg seems to be more straightforward to me. If you are going to remove the input device section (generation) completely from xserver-xorgs postinst and rely completely on hal for that, then I agree hal should be the one and only place where to configure the keyboard/input. Doing the configuration at two places (xserver-xorg->xorg.conf and hal-> fdi) will really cause headaches imho. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 01:53:40PM +0300, Daniel Stone wrote: > On Tue, Oct 23, 2007 at 08:17:10PM -0400, ext David Nusinow wrote: > > On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: > > > On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > > > > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > > > > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > > > > layout is used. > > > > > > Yes, this should probably be fixed up, I guess. But the long-term fix > > > is to provide an FDI file in /etc that specifies the keyboard layout. > > > > My feeling is the other way around, provided that the X server is the only > > user of this field. People already know how to edit xorg.conf, and they > > expect it. Telling them to edit a relatively obscure file among many other > > fdi's is more painful. There's also userspace tools that exist to help with > > generating a xorg.conf, but nothing friendly to deal with fdi's. > > As I've said before, the X server isn't the only user of the field. :) > Ubuntu were trying to move to cxkb a year or so ago, and the only thing > that stopped them in the end was how huge the XKB codebase was, which > I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets > us finaly unify console and X keymaps ... Ok, I missed that somehow. So it should probably be hal that generates this and not the xserver? > > > > Preferably, the X server should use the keyboard layout specified in > > > > xorg.conf (for the old kbd driver) even when used in xorg hotplugging > > > > mode. > > > > > > Yes, probably. > > > > My sense is that if we're going to do this, then there's no need to > > generate the fdi. Just generate the xorg.conf. We can patch the server to > > use libhal_device_set_property_string to dynamically set the keyboard > > layout at runtime in hal's database, and the server can just draw that > > information from xorg.conf initially. > > Well, you could even have a postinst that scans xorg.conf and generates > the FDI, but yes, the X server should be responsible for checking this > and not breaking existing setups. Yeah, I'm mainly concerned with not breaking existing setups. I feel like we've been doing that a lot lately. Luckly, lenny is a ways away so we have time to break things quite a bit before we get it right. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 15:54:05 +0300, Daniel Stone wrote: > On Wed, Oct 24, 2007 at 02:47:06PM +0200, ext Julien Cristau wrote: > > On Tue, Oct 23, 2007 at 20:02:31 +0200, Michael Biebl wrote: > > > You were right, Julien. It was because of hal (specifically the file > > > /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi) that the evdev > > > driver was enabled. > > > > BTW, should we change the fdi to load synaptics instead of evdev when it > > detects a touchpad? It seems most people are using that. > > Yep, seems sensible to me. OK. Michael, the following patch seems to work for me: --- 10-x11-input.fdi2007-10-24 15:07:22.0 +0200 +++ 10-x11-input.fdi.new2007-10-24 15:07:58.0 +0200 @@ -7,6 +7,9 @@ evdev + + synaptics + > > > I'm using evdev right now on my laptop, but I need to run xinput to set > > the device to relative mode every time I start X (and I had to modify > > xinput to let me do that, because it doesn't think my touchpad is an > > extended device). > > Ah, yes. I assume it was just checking for XExtensionDevice, instead of > Device/Keyboard/Pointer? > Right. Cheers, Julien signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Wed, Oct 24, 2007 at 02:47:06PM +0200, ext Julien Cristau wrote: > On Tue, Oct 23, 2007 at 20:02:31 +0200, Michael Biebl wrote: > > You were right, Julien. It was because of hal (specifically the file > > /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi) that the evdev > > driver was enabled. > > BTW, should we change the fdi to load synaptics instead of evdev when it > detects a touchpad? It seems most people are using that. Yep, seems sensible to me. > I'm using evdev right now on my laptop, but I need to run xinput to set > the device to relative mode every time I start X (and I had to modify > xinput to let me do that, because it doesn't think my touchpad is an > extended device). Ah, yes. I assume it was just checking for XExtensionDevice, instead of Device/Keyboard/Pointer? Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 20:02:31 +0200, Michael Biebl wrote: > You were right, Julien. It was because of hal (specifically the file > /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi) that the evdev > driver was enabled. > BTW, should we change the fdi to load synaptics instead of evdev when it detects a touchpad? It seems most people are using that. I'm using evdev right now on my laptop, but I need to run xinput to set the device to relative mode every time I start X (and I had to modify xinput to let me do that, because it doesn't think my touchpad is an extended device). Cheers, Julien signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 08:17:10PM -0400, ext David Nusinow wrote: > On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: > > On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > > > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > > > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > > > layout is used. > > > > Yes, this should probably be fixed up, I guess. But the long-term fix > > is to provide an FDI file in /etc that specifies the keyboard layout. > > My feeling is the other way around, provided that the X server is the only > user of this field. People already know how to edit xorg.conf, and they > expect it. Telling them to edit a relatively obscure file among many other > fdi's is more painful. There's also userspace tools that exist to help with > generating a xorg.conf, but nothing friendly to deal with fdi's. As I've said before, the X server isn't the only user of the field. :) Ubuntu were trying to move to cxkb a year or so ago, and the only thing that stopped them in the end was how huge the XKB codebase was, which I'm fixing (very slowly) upstream. So yeah, if having this in HAL lets us finaly unify console and X keymaps ... > > > Preferably, the X server should use the keyboard layout specified in > > > xorg.conf (for the old kbd driver) even when used in xorg hotplugging > > > mode. > > > > Yes, probably. > > My sense is that if we're going to do this, then there's no need to > generate the fdi. Just generate the xorg.conf. We can patch the server to > use libhal_device_set_property_string to dynamically set the keyboard > layout at runtime in hal's database, and the server can just draw that > information from xorg.conf initially. Well, you could even have a postinst that scans xorg.conf and generates the FDI, but yes, the X server should be responsible for checking this and not breaking existing setups. Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 10:02:35PM +0300, Daniel Stone wrote: > On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > > layout is used. > > Yes, this should probably be fixed up, I guess. But the long-term fix > is to provide an FDI file in /etc that specifies the keyboard layout. My feeling is the other way around, provided that the X server is the only user of this field. People already know how to edit xorg.conf, and they expect it. Telling them to edit a relatively obscure file among many other fdi's is more painful. There's also userspace tools that exist to help with generating a xorg.conf, but nothing friendly to deal with fdi's. > > If I understood Daniel correctly, he proposes to set the keyboard layout > > (probably based on the values from xorg.conf) via a generated fdi file. > > I'd like to avoid that, because that would complicate things. > > How would it complicate anything? xorg.conf is a file, so is an FDI. > We're already using FDIs through HAL, anyway ... Generating xorg.conf sucks though and we're trying to get away from that as much as is sensible. Of course, this was the one section I'd planned to keep generating anyway. > > Preferably, the X server should use the keyboard layout specified in > > xorg.conf (for the old kbd driver) even when used in xorg hotplugging mode. > > Yes, probably. My sense is that if we're going to do this, then there's no need to generate the fdi. Just generate the xorg.conf. We can patch the server to use libhal_device_set_property_string to dynamically set the keyboard layout at runtime in hal's database, and the server can just draw that information from xorg.conf initially. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
On Tue, Oct 23, 2007 at 08:02:31PM +0200, ext Michael Biebl wrote: > Whenever xorg input hotplugging kicks in, the evdev driver is used. The > kbd keyboard settings from xorg.conf are ignored and the en_US keyboard > layout is used. Yes, this should probably be fixed up, I guess. But the long-term fix is to provide an FDI file in /etc that specifies the keyboard layout. > Unfortunately, the evdev driver seems to lack functionality, e.g. my > multimedia keys don't work anymore, also, very important, STRG+ALT+F1 is > non-functional (maybe this is just a misconfiguration, I don't know. At > least the default configuration seems to lack this functionality). Sounds like the keymap isn't getting loaded correctly; it's always worked fine here. > It gets even worse, if you try to apply a pc105 keyboard layout over > evdev (which can happen if you use GNOMEs/KDEs keyboard selector). Then > you not only have missing keys but also some keys are mis-mapped. E.g. > the UP key is mapped to PRINT [1]. This really makes it hard to navigate. Use the evdev layout, not pc105. > If I understood Daniel correctly, he proposes to set the keyboard layout > (probably based on the values from xorg.conf) via a generated fdi file. > I'd like to avoid that, because that would complicate things. How would it complicate anything? xorg.conf is a file, so is an FDI. We're already using FDIs through HAL, anyway ... > Preferably, the X server should use the keyboard layout specified in > xorg.conf (for the old kbd driver) even when used in xorg hotplugging mode. Yes, probably. > For the second part (DEs applying a pc105 keyboard layout over evdev) I > can't think of a proper solution right now. All I can say is, that I > would prefer, if we don't break working setups. Unfortunately, there's not much we can do here, except possibly the evdev driver hacking pc105 to evdev. Cheers, Daniel signature.asc Description: Digital signature
Bug#442316: Xorg hotplugging problems [WAS: Re: Bug#442316: xserver-xorg-input-evdev: evdev from experimental messes up my keyboard layout]
Julien Cristau schrieb: > On Sat, Sep 15, 2007 at 02:15:52 +0200, Michael Biebl wrote: > >> Package: xserver-xorg-input-evdev >> Version: 1:1.2.0~git20070819-2 >> Severity: important >> >> As you can see from the xorg.conf, I set up a German keyboard layout. >> After installing evdev from experimental I lost my German >> keyboard layout (I guess its english, y is z e.g.). >> Also, my special keys like alt+f1 dont work anymore. >> > Hrm. I'm not sure why evdev is even loaded. Did you enable input > hotplug via hal? You were right, Julien. It was because of hal (specifically the file /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi) that the evdev driver was enabled. Whenever xorg input hotplugging kicks in, the evdev driver is used. The kbd keyboard settings from xorg.conf are ignored and the en_US keyboard layout is used. Unfortunately, the evdev driver seems to lack functionality, e.g. my multimedia keys don't work anymore, also, very important, STRG+ALT+F1 is non-functional (maybe this is just a misconfiguration, I don't know. At least the default configuration seems to lack this functionality). It gets even worse, if you try to apply a pc105 keyboard layout over evdev (which can happen if you use GNOMEs/KDEs keyboard selector). Then you not only have missing keys but also some keys are mis-mapped. E.g. the UP key is mapped to PRINT [1]. This really makes it hard to navigate. Since the latest upgrade of hal to 0.5.10, the above fdi file is shipped by default in hal. So several users have already encountered this problem (debian bug #447666, #447676). The question now is, how we proceed from here. I CCed Daniel Stone, maybe he can give us some input on how to solve this, and how we can get xorg hotplugging work correctly. If I understood Daniel correctly, he proposes to set the keyboard layout (probably based on the values from xorg.conf) via a generated fdi file. I'd like to avoid that, because that would complicate things. Preferably, the X server should use the keyboard layout specified in xorg.conf (for the old kbd driver) even when used in xorg hotplugging mode. For the second part (DEs applying a pc105 keyboard layout over evdev) I can't think of a proper solution right now. All I can say is, that I would prefer, if we don't break working setups. In case we can't fix the above issues in a reasonable time frame, I will consider to remove /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi from hal again, at least temporarily. If you say, that this is soon fixable, I would at least raise the severity of the hal bug #447666 to critical, so users of testing will not be affected by this. Feedback and comments welcome, Michael [1] http://lists.freedesktop.org/archives/xorg/2007-October/029202.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
