[PATCH] Fix XKB options passed from HAL

[Daniel Stone]

On Mon, Dec 03, 2007 at 02:34:49PM -0200, Paulo Cesar Pereira de Andrade wrote:
> Daniel Stone wrote:
>> Again, this isn't config/hal.c, this is hw/xfree86.
>> NewInputDeviceRequest should just walk the config tree and DTRT,
>> potentially calling down into the drivers to ask, 'are you handling
>> this?'.  This is why NIDR exists.
>
>  This maybe a bit late (or too early if one changes the code to
> load hal specified devices before xorg.conf ones).

???

config/hal.c doesn't add any devices at all: it merely suggests that the
DDX may want to do so.  If you parse the configuration first (and you
do, because you only connect to D-Bus in your first run through
WaitForSomething, as it's hanging off a timer), then you just make
NewInputDeviceRequest check the list of configured devices from
xorg.conf, and do nothing if there's already a matching device.

> And expecting
> NewInputDeviceRequest to fix the fact that hal devices cannot map
> to xorg.conf devices may be too much to ask.

Er?

XFree86 devices are valid _only_ in hw/xfree86.  NewInputDeviceRequest
is in hw/xfree86.  config/hal.c ... is not.  This is in fact basically
the only place where you could do this mapping.

>  IMO the proper fix is to match the xorg.conf input device
> section with the hal section (don't ask me how to do it, I don't
> know, that's why I filled the bug report
> https://bugs.freedesktop.org/show_bug.cgi?id=13361),
> if the xorg.conf code and hal code coexist in the X Server, and
> "one doesn't know about the other" and both load one module to
> handle the same input device, things are unlikely to work properly.

Of course not.  But the reason NewInputDeviceRequest _exists_ is so the
DDX can decide what to do with hints as to whether to add input devices.
For Xvfb, the answer is to ignore them completely.  For KDrive, the
answer is[0] to ignore them if you already have a similar device on the
command line.  For Xorg, the answer would be to ignore them if you've
already got a very similar device configured.

Doing it in config/hal.c is literally impossible, as the input
infrastructure is DDX-specific.  Just do it in NewInputDeviceRequest;
it's actually really easy.  There are a couple of options:
  * Add driver hooks to query a certain device if it already owns this,
    then query all devices at NIDR.  For kbd and mouse, always return
    true; for evdev, return true if the paths are identical.
  * Do almost exactly the same inside NIDR itself.

The only problem I see here is with symlinks, but, well, life's tough.

> And the EVIOCGRAB ioctl should not be a justification to have
> 2 different modules handling the same device. It works with
> evdev, but the mouse driver, as I reported earlier will generate
> duplicated events, and mixing evdev with kbd and mouse is wrong.

Well, having kbd and mouse around at all is 'wrong', really.

Cheers,
Daniel

[0]: An examination of the code shows that this is not currently the
     case, but I do have a firm recollection of writing that code.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20071203/a828b3d8/attachment.pgp>