I also forgot to say that on my upgraded system with vdev and
arch version of xf86-input-evdev touchpad gets detected and loaded that
I believe is
fascilitated by evdev and libudev-compat??

best regards


Scooby


On 2015-09-05 21:40, shraptor wrote:
> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng