[guide] xorg-xserver input hotplug + evdev

lloeki · 2008-02-13 13:51:50

EDIT: there's now a wiki entry.

this is how I enabled all special keyboard and mouse extra buttons, wheels and whatever, with full real hotplug support via hal and dbus.

as of currently, Arch's xorg-server 1.4.0.90-6, X11 <-> hal support is disabled. you have to enable it.

get the xorg-xserver PKGBUILD+other files from abs the usual way (see ABS howto if necessary), and alter ./configure options in the PKGBUILD:
- change --enable-dmx to --disable-dmx (dmx is not yet compatible with new device system)
- check that you have --disable-xprint (it should be so already, compile will fail with xprint enabled)
- remove --disable-config-hal (obviously)

then build and install the resulting package (pacman -U).

we have to allow the xorg server to listen to hal via dbus. so, create this file (or copy it from the xorg-server source):

$ cat /etc/dbus-1/system.d/xorg-server.conf 
<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
    <policy context="default">
        <allow own="org.x.config.display0"/>
        <allow send_destination="org.x.config.display0"/>
        <allow send_interface="org.x.config.display0"/>
        <allow own="org.x.config.display1"/>
        <allow send_destination="org.x.config.display1"/>
        <allow send_interface="org.x.config.display1"/>
    </policy>
</busconfig>

evdev devices not only include mice but also keyboards, and unfortunately once the server queries hal, it will discard your xong.conf keyboard configuration. so let's inform hal of the real layout:

$ cat /etc/hal/fdi/policy/11-kb.fdi 
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
        <!-- ignore Windows drive -->
    <device>
        <match key="info.product" string="AT Translated Set 2 keyboard">
            <merge key="input.xkb.layout" type="string">fr</merge>
        </match>
    </device>
</deviceinfo>

of course, change the match key to something relevant for you (use gnome-device-manager with view->device properties enabled to easily browse the hal tree, or grep lshal output), change 'fr' to your layout. you may also want to merge other keys like input.kxb.variant.

now for the last bit. historically, the xorg server needs a CoreKeyboard and a CorePointer, other extra devices merely sending core events. usually you set them in xorg.conf. if there's none in the config, some recent xorg server version allows for automatic finding of those Core devices by looking into /dev/input. notably, it will always find /dev/input/mice and create a default ExplorerPS/2 mouse with it (which is bad for us as we want evdev), as it's a sink device where all mice send events in a restricted way (that's why evdev can't use it, and if you use it it'll lack many buttons, because of the PS/2 fallback). so let's get rid of it as its purpose was precisely to be a workaround for hotplugging, which we now have properly implemented.

add this in your xorg.conf

Section "ServerFlags"
    Option "AllowEmptyInput"
EndSection

also, you will want to remove any input device from xorg.conf, except your synaptics touchpad (and other special drivers I may not be aware of), so that's any device whose driver should be 'mouse', or 'evdev', or 'keyboard'. don't forget to remove both the input device section and the entry in server layout section.

now, restart X, plug and unplug your mouse at will, and observe /var/log/Xorg.0.log output as it loses and sets your input devices.

in hope this helps someone, as I had a hard time gathering all this information. documentation is really lacking and/or outdated...

Last edited by lloeki (2008-04-10 08:02:40)

Phrodo_00 · 2008-02-28 21:28:23

Hey, thanks, I'm trying this right now. You should really make a package in aur to do this, something like xorg-xserver-hal that provides xorg-xerver and does the configure thing and copy /etc/dbus-1/system.d/xorg-server.conf to its place (in the package)... it'd be pretty cool, even more if some guy with a repo hosted it. btw ¿isn't there any other way? ¿something like xrandr but for input? I looked for hotplugging in google and I ended up here so you're pretty right about not existing info.
btw, patching is pretty slow in a 1ghz celeron.

lloeki · 2008-02-28 21:53:26

an xorg-server version with this is in the official testing repo.

there's no other way to have real hotplugging. this is indeed what one might relate to xrandr for its display hotplugging ability, and it's called xinput. it is in the process of a huge revamp, first with this hotplug support, and next with MPX (multi-pointer X) in the near future.

Last edited by lloeki (2008-02-28 21:58:32)

Zibi1981 · 2008-02-28 22:35:24

lloeki, you should start a wiki entry or something similair with this content

Last edited by Zibi1981 (2008-02-28 22:38:19)

shining · 2008-02-28 23:19:27

Zibi1981 wrote:

lloeki, you should start a wiki entry or something similair with this content

If you do, don't take into account that this is available in testing. It might be reverted as many users apparently have problems with it.

RobbeR49 · 2008-02-29 14:52:35

lloeki wrote:

in hope this helps someone, as I had a hard time gathering all this information. documentation is really lacking and/or outdated...

I worked through a lot of this a month or so ago, and you're right, the documentation for all of this is terrible. But you've done a good job putting it all together, much more thorough than the short explanation I gave in an earlier thread. IMO Definitely deserves wikifying.

Phrodo_00 · 2008-02-29 15:53:06

I compiled it in my slow laptop and the compile failed ... after around 4 hours... I'll keep trying, but I'll build it in my desktop.

lloeki · 2008-03-13 10:34:41

this was a long time since I started a game. it seems that with evdev, dga gets broken in sdl: mouse jumps and moves down-right all the time.

to fix this you have to either set a var:

export SDL_VIDEO_X11_DGAMOUSE=0

or add to your xorg.conf:

Section "Module"
    ...
    SubSection  "extmod"
      Option    "omit xfree86-dga"   # don't initialise the DGA extension
    EndSubSection
    ...
EndSection

the latter is mandatory for e.g doom3

Last edited by lloeki (2008-03-13 10:35:18)

mildred · 2008-03-16 15:05:34

Hi,

Just a question, you said that you had to leave the synaptics section in xorg.conf ... So does it means that synaptics doesn't handle hotplugs events ?

I'm asking that because I'm trying to get synaptics handle these hotplugs events, because when I suspend my laptop, my (USB) trackpad gets powered off, and when I resume my laptop, its gets reconnected (and gets another input device). So synaptics stops functionning (until I switch to the linux virtual terminal and back to X).
If synaptics could handle hitplug events, it would just detect another trackpad ... directly.

Thanks

Mildred.

big_gie · 2008-03-16 15:55:11

Hi lloeki,

I tried xorg-server from testing with HAL enable, but it messed my keyboard. I could not have the same config as with my xorg.conf...

The problem was that some keys were not mapped to the right placed. For example, the up arrow got mapped to print screen, etc.

Here is my xorg.conf related section:

Section "InputDevice"
    Identifier  "Keyboard0"
    Driver      "keyboard"
    Option      "CoreKeyboard"
    Option      "XkbRules"    "xorg"
    Option      "XkbModel"    "pc105"
    Option      "XkbLayout"   "ca(fr)"
EndSection

I think the problem might be with the "XkbModel" as pc105. My laptop, a Dell Latitude D830, has 74 keyboard keys... I did not tried US layout though... ca(fr) is similar to us, except for accents.

I reinstalled non-testing xorg-server for now. I need to work

Any ideas?

lloeki · 2008-03-17 19:35:47

mildred, I'll do some research on the synaptics side. I just didn't bother to coonf it via hal because I'm on a laptop, and I obviously never disconnect my touchpad so I don't need hotplug for it.

big_gie, I'll look into this issue too, bu tyou could try to set the 'input.xkb.model' hal key in the fdi to pc105 instead of evdev, or even deleting the whole match on Linux block.
I'll do some testing here too.

Jan,

Closed by Jan de Groot (JGC)
Monday, 17 March 2008, 00:11 GMT+1
Reason for closing: Won't implement
Additional comments about closing: The hal backend breaks too many things here. It even takes X down without warning on an X upgrade. Reverting.

argh! well, I won't request reopen until some things have been worked out.
what does 'takes X down here' mean? you mean you upgraded from inside X, and X crashed at once? or once upgraded, X fails to restart?
also, what 'breaks too many things here' means? which things, and what do you mean by 'here'? your computer(s)? or arch in general?

I'll create some wiki page in the coming days. I'd like to have as much feedback as possible to investigate and document workarounds and solutions in this page.

Last edited by lloeki (2008-03-17 19:40:59)

shining · 2008-03-17 20:37:57

lloeki wrote:

also, what 'breaks too many things here' means? which things, and what do you mean by 'here'? your computer(s)? or arch in general?

It has been mentioned several times on the ML, here is the last reference I think :
http://archlinux.org/pipermail/arch-dev … 05248.html

lloeki · 2008-03-17 22:13:06

thanks for the pointer.

I guess I should really subscribe to the ML.

lloeki · 2008-03-27 15:16:11

I'll create some wiki page in the coming days.

I had a nasty car crash the day after. Still recovering. I hope to put it online before next week.

retsaw · 2008-03-29 23:15:56

I'm curious, what is the actual benefit of this? I don't have a problem hotplugging keyboards and mice with a normally configured Xorg server.

schivmeister · 2008-03-30 07:05:11

Special devices don't really get all the bling automatically..like 100-button mice.

lloeki · 2008-04-07 16:00:56

wiki entry

big_gie · 2008-04-07 16:08:38

How's the health? I hope the crash was not to bad :S

lloeki · 2008-04-08 08:10:16

five vertebras (one cervical, four thoracic) have moved (fixed by osteopathy) plus ligament traumas (just have to wait, already feeling better, I only have some residual pain and stiffness in the neck)
additionally a vicious hidden hematoma on the left clavicle and sternum, seen via ultrasonography. caused by the 3pt seatbelt auto-tightening, which hopefully prevented my head from hitting the roof (since I ended up upside down). this one is usually painless, except on certain moves, where I suffer a thousand deaths during a split second (the radiographer warned me about it, and I never expected it to be so true). It should last up to 6 months.

all in all I was very lucky, and although no airbag popped out, technology like progressive deformation basically saved me from any irreversible body damage.

Last edited by lloeki (2008-04-08 08:16:21)

kludge · 2008-12-31 08:14:52

hey lloeki,

i can't find this anywhere else, so i thought i'd ask you:

i have no use for hotplugging, and having no use for hotplugging, i have no use for hal. so i'm working on a pkgbuild of xorg-server with no hal dependency. that requires --config-disable-hal. so far so good.

but there's also --enable-config-dbus. i can't find a firm answer out there, but it seems like dbus can be used as an alternate mechanism for hot-plugging.

questions:

* will --enable-config-dbus make hotplugging available without hal?
* will *not* enabling dbus break anything else?

if you have any insight, it'd be much appreciated. thank you!

Last edited by kludge (2008-12-31 08:17:02)

lloeki · 2009-01-04 21:06:43

if you don't mind having hal installed (though not running), there's a xorg.conf server setting to tell him not to use hal.
dbus is the freedesktop initiative to have a generic, controllable, language independent IPC mechanism, and just that (IPC). i.e it's a means, not an end. it may be used e.g for some software to get x server info via elsewhere than standard xlib calls. this is also the mediator between hal and other software, such as the x server. so will it make hotplugging available? not by itself, but it's mandatory for hal to communicate with the world. will not enabling it break anything? I don't really know, but I suppose the DE triptic (XFCE, KDE, GNOME) may use that to gather info about the x server via dbus.

kludge · 2009-01-04 23:42:04

lloeki wrote:

if you don't mind having hal installed (though not running), there's a xorg.conf server setting to tell him not to use hal.

yeah, got that. i *do* ming having hal installed if i'm not using... hence the questions.

dbus is the freedesktop initiative to have a generic, controllable, language independent IPC mechanism, and just that (IPC). i.e it's a means, not an end. it may be used e.g for some software to get x server info via elsewhere than standard xlib calls. this is also the mediator between hal and other software, such as the x server. so will it make hotplugging available? not by itself, but it's mandatory for hal to communicate with the world. will not enabling it break anything? I don't really know, but I suppose the DE triptic (XFCE, KDE, GNOME) may use that to gather info about the x server via dbus.

thanks! i went ahead and disabled it.

Arch Linux

#1 2008-02-13 13:51:50

[guide] xorg-xserver input hotplug + evdev

#2 2008-02-28 21:28:23

Re: [guide] xorg-xserver input hotplug + evdev

#3 2008-02-28 21:53:26

Re: [guide] xorg-xserver input hotplug + evdev

#4 2008-02-28 22:35:24

Re: [guide] xorg-xserver input hotplug + evdev

#5 2008-02-28 23:19:27

Re: [guide] xorg-xserver input hotplug + evdev

#6 2008-02-29 14:52:35

Re: [guide] xorg-xserver input hotplug + evdev

#7 2008-02-29 15:53:06

Re: [guide] xorg-xserver input hotplug + evdev

#8 2008-03-13 10:34:41

Re: [guide] xorg-xserver input hotplug + evdev

#9 2008-03-16 15:05:34

Re: [guide] xorg-xserver input hotplug + evdev

#10 2008-03-16 15:55:11

Re: [guide] xorg-xserver input hotplug + evdev

#11 2008-03-17 19:35:47

Re: [guide] xorg-xserver input hotplug + evdev

#12 2008-03-17 20:37:57

Re: [guide] xorg-xserver input hotplug + evdev

#13 2008-03-17 22:13:06

Re: [guide] xorg-xserver input hotplug + evdev

#14 2008-03-27 15:16:11

Re: [guide] xorg-xserver input hotplug + evdev

#15 2008-03-29 23:15:56

Re: [guide] xorg-xserver input hotplug + evdev

#16 2008-03-30 07:05:11

Re: [guide] xorg-xserver input hotplug + evdev

#17 2008-04-07 16:00:56

Re: [guide] xorg-xserver input hotplug + evdev

#18 2008-04-07 16:08:38

Re: [guide] xorg-xserver input hotplug + evdev

#19 2008-04-08 08:10:16

Re: [guide] xorg-xserver input hotplug + evdev

#20 2008-12-31 08:14:52

Re: [guide] xorg-xserver input hotplug + evdev

#21 2009-01-04 21:06:43

Re: [guide] xorg-xserver input hotplug + evdev

#22 2009-01-04 23:42:04

Re: [guide] xorg-xserver input hotplug + evdev

Board footer