[PATCH 5/6] Allow compiling against older headers

[Dmitry Torokhov]

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.

Thanks,
Dmitry