[PATCH 5/6] Allow compiling against older headers

[Dmitry Torokhov]

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.

Thanks,
Dmitry