[PATCH xorg-gtest 16/16] Add Device::GetDeviceNode() to return device node path from an evemu device

[Peter Hutterer]

On Fri, Jul 06, 2012 at 11:11:55AM -0700, Chase Douglas wrote:
> On 07/05/2012 04:41 PM, Peter Hutterer wrote:
> >On Thu, Jul 05, 2012 at 02:19:33PM -0700, Chase Douglas wrote:
> >>On 07/03/2012 11:03 PM, Peter Hutterer wrote:
> >>>On Tue, Jul 03, 2012 at 11:40:25AM -0700, Chase Douglas wrote:
> >>>>On 07/02/2012 11:44 PM, Peter Hutterer wrote:
> >>>>>evemu doesn't export this information and even evemu-device just trawls
> >>>>>through the file system to print this info. So do the same here, noting the
> >>>>>time before evemu_create() and the ctime of the new device file. If the
> >>>>>latter is later than the former and the device names match, we can assume
> >>>>>this is our device.
> >>>>
> >>>>I just want to point out that it's a deficiency in uinput, not in
> >>>>evemu, in case anyone had any thoughts of trying to fix evemu
> >>>>instead.
> >>>
> >>>I did try. This could easily be part of evemu, running this exact same code
> >>>right after the UI_DEV_CREATE call. Unfortunately evemu_create() takes a
> >>>const struct so we can't save it easily without breaking ABI.
> >>
> >>Well, evemu could try to guess, just as this code does. What I meant
> >>was more that uinput is deficient in that there's no way to be 100%
> >>sure. That's the main reason why we didn't bother putting code like
> >>this into evemu directly.
> >
> >the one advantage evemu has though is that it's in the best position
> >to guess given that it just created the device and has easy access to all
> >other information. plus, it wouldn't require duplicating the code across
> >other projects.
> 
> Yeah, good point. Maybe I should just take the
> find_newest_device_node_with_name function in evemu-device.c and
> copy it into the library proper?

yeah, it wouldn't hurt to have it there.

Cheers,
  Peter