[PATCH 5/6] Allow compiling against older headers

[Dmitry Torokhov]

On Thu, Sep 28, 2017 at 4:45 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> 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.

Ah, I must have grabbed pretty old one then...

Thanks,
Dmitry