[PATCH 5/6] Allow compiling against older headers

[Peter Hutterer]

On Thu, Sep 28, 2017 at 04:31:01PM -0700, Dmitry Torokhov wrote:
> On Thu, Sep 28, 2017 at 4:02 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > On Thu, Sep 28, 2017 at 03:33:04PM -0700, Dmitry Torokhov wrote:
> >> On Thu, Sep 28, 2017 at 3:04 PM, Peter Hutterer
> >> <peter.hutterer at who-t.net> wrote:
> >> > On Thu, Sep 28, 2017 at 02:20:02PM -0700, Dmitry Torokhov wrote:
> >> >> Hi Peter,
> >> >>
> >> >> On Thu, Sep 28, 2017 at 2:05 PM, Peter Hutterer
> >> >> <peter.hutterer at who-t.net> wrote:
> >> >> > On Wed, Sep 27, 2017 at 10:58:30AM -0700, Dmitry Torokhov wrote:
> >> >> >> Instead of requiring to compile against the newest kernel headers or
> >> >> >> lose newer certain event definitions, let's check for the presence of
> >> >> >> "official" defines and add missing ones ourselves (they form ABI so
> >> >> >> there is no risk of them changing and getting out of sync). This allows
> >> >> >> us to produce fully-functional version of evtest even if kernel headers
> >> >> >> on the build system are slightly older.
> >> >> >>
> >> >> >> Signed-off-by: Dmitry Torokhov <dtor at chromium.org>
> >> >> >
> >> >> > tbh, I'm not a big fan of this patch. The main reason I'm keeping evtest
> >> >> > alive is because it's a single file and can still be compiled with a simple
> >> >> > 'gcc evtest.c' without having to worry about automake, dependencies, etc.
> >> >> > Once that advantage goes away evtest is a less-featureful cousin to
> >> >> > evemu-record. And that has the advantage of being replayable.
> >> >> >
> >> >> > That aside, Martin's suggestion of just adding linux/input(-event-codes).h
> >> >> > would be a better choice here, that should keep the `gcc evtest.c` option
> >> >> > alive.
> >> >>
> >> >> I must say that I am terribly confused as to how my patch breaks
> >> >> "naked" gcc compilation and why Martin's suggestion would be any
> >> >> different in this regard:
> >> >>
> >> >> dtor at dtor-ws:~ $ git clone evtest evtest-tmp
> >> >> Cloning into 'evtest-tmp'...
> >> >> done.
> >> >> dtor at dtor-ws:~ $ cd evtest-tmp/
> >> >> dtor at dtor-ws:~/evtest-tmp $ gcc -o evtest evtest.c
> >> >> dtor at dtor-ws:~/evtest-tmp $ sudo ./evtest
> >> >> [sudo] password for dtor:
> >> >> No device specified, trying to scan all of /dev/input/event*
> >> >> Available devices:
> >> >> /dev/input/event0:      Power Button
> >> >> /dev/input/event1:      Power Button
> >> >> /dev/input/event2:      HDA Intel PCH Front Mic
> >> >> /dev/input/event3:      HDA Intel PCH Rear Mic
> >> >> /dev/input/event4:      HDA Intel PCH Line
> >> >> /dev/input/event5:      HDA Intel PCH Line Out
> >> >> /dev/input/event6:      HDA Intel PCH Front Headphone
> >> >> /dev/input/event7:      HP WMI hotkeys
> >> >> /dev/input/event8:      HDA NVidia HDMI/DP,pcm=3
> >> >> /dev/input/event9:      HDA NVidia HDMI/DP,pcm=7
> >> >> /dev/input/event10:     HDA NVidia HDMI/DP,pcm=8
> >> >> Select the device event number [0-10]:
> >> >
> >> > sorry, I should've said: you can curl/wget evtest.c without git and compile
> >> > it without dependencies. You can still do that with two files of course, but
> >> > it's just that extra step.
> >>
> >> I see. We could put all these defines into evtest.c. it will be a bit
> >> uglier, but will allow your use case.
> >>
> >> >
> >> > any particular reason you're using evtest btw instead of evemu?
> >>
> >> Muscle memory on my Linux boxes and we did not need facilities
> >> provided by evemu on ChromeOS so far; evdev UI is better for casual
> >> users. In fact, we looking at a patch that enables "safe" mode of
> >> evtest that suppresses key codes, scan codes, and timing data, and
> >> want to allow evdev in safe mode in out "crosh" shell so we can see if
> >> input devices is alive from kernel POV under cerain circumstances.
> >
> > What UI do you need from evemu? Having a safe tool like this seems to
> > be a useful addition to evemu too.
> 
> The list of devices it produces when called without device node and
> the ability to select by number.

that's been there since 2013, just call evemu-record (or evemu-describe if
you just care about the static description) without arguments.

Cheers,
   Peter