Just to be clear my system before upgrade was using vdev in conjunction
with
xf86-input-evdev and working fine. I did not recompile that version of
evdev and it
just worked with libudev-compat.

When I upgraded to new version of both( and new kernel)
keyboard stopped working( though could be brought to life with static
conf in xorg.conf.d).

I thought maybe arch had done something to break functionality
here. It could also be some regression in vdev and I will speak
to jude about that after September 12 when he's got more time.


@Jack Frost
I do not understand the use of .pc files although I have seen them
around. I am using your systemd-dummy package though to avoid pulling
in real systemd, Thanks for that.


Isaac I know about your package and have checked it out before
but didn't fully understand it.

What is triggering evdev in your case? a file in xorg.conf.d?

I am gonna try your solution with libsysdev and sysdev branch
of xf86-input-evdev. Although it would easier( for me that is) if
the arch version just worked with vdev.

I love that you give full explanation, thanks

best regards


Scooby





On 2015-09-05 20:36, Isaac Dunham wrote:
> On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
>> On arch linux xf86-input-evdev is reported to have a dependency on
>> systemd.
>>
>> I thought the dependency is on udev and that is usually reported on
>> arch
>> like
>> systemd(udev).
>>
>> I downloaded xf86-input-evdev for recompilation but could not find any
>> switches
>> to compile without systemd though some evidence pointing at a udev
>> dependency was there.
>>
>> Does anyone know?
>
> Long explanation here.
>
> xf86-input-evdev, as shipped by upstream, is intended to be loaded by
> Xorg's
> hotplug support, which depends on libudev (or an API-compatible
> replacement
> such as libudev-compat or libeudev...); at least in theory, you can
> also
> use it as a pre-configured device driver.
> The hotplug path will load evdev for *all* input devices that are
> hotplugged--power buttons included.
>
> So, evdev needs to check if a device is "virtual".
> This is a simple matter of checking that the canonical path in sysfs
> contains the string "LNXSYSTM".
> Getting that canonical path is the hard part, since you receive a
> device
> path instead of anything pointing into sysfs.
>
> This can be done more-or-less by getting the device major and minor
> via stat(), checking that it's a char device, then identifying the
> corresponding link in /sys/dev/ - this would be the string returned by:
> sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
> and then use readlink() to check where it points; the result is the
> canonical path.
>
> However, most people prefer to avoid depending on the sysfs layout even
> where its behavior is documented; libudev provides a thin veneer to
> hide
> it.
> So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to
> do
> this.
> There is no dependency on udev being running.
>
> I've redone that function without udev but using my own library
> libsysdev,
> which I mentioned earlier this summer.
> Repositories that you'd need to build that:
>
> -https://github.com/idunham/libsysdev
> -https://github.com/idunham/xf86-input-evdev (branch sysdev)
>
> But that does require something that has no Debian packaging yet.
>
> There are also two other options:
> - comment out that function and disable device hotplug in Xorg.conf or
> xorg.conf.d
> - replace the function with one that does all the work itself.
>
> HTH,
> Isaac Dunham