[PATCH 5/6] Allow compiling against older headers

[Peter Hutterer]

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 only real difference between evtest and evemu is that the human-readable
output from evemu is after the magic bits that are replayable (and can be
ignored by puny humans). Since the human-readable bits are only comments, we
can change them if needed.

Likewise, adding an evemu-safe [1] tool is easy enough. if the tool has a
different name, it avoids users forgetting the magic safety switch and
attaching passwords to bugs.

Cheers,
   Peter

[1] with a better name of course