AutoCursor extension submitted

[jazzbiker]

Hi, Rich!

Now AutoCursor works without any issues. Any configuration of hiding and showing devices can be described and provided. But if some time You will be in the mood to introduce some changes into it, I have the proposal for You.

Now the sequence of actions is the following:
1. Processing "h" and "s" parameters, catching "L" and "S" names.
2. Saving supplied "h" and "s" values in the "S" name.
3. If present, load "L" name and, thereby, forgetting supplied int the command line values.

I think, sometimes it would be convenient to change the sequence:
1. as before
2. Loading, if present, "L" file and appending values in it to the existing list of command line "h" and "s" values.
3. If needed, save the resulting list to the "S" file.

What can You say about?

[Rich]

Hi jazzbiker
I'm not going to check for and support every possible combination of load, save, and command line switches.
This is a utility that typically would get run once or twice to set it up, and then launched automatically from ~/.X.d.
I did make 2 changes. I adjusted file permissions to 666 when saving settings. This way you don't need to be root to edit it.
I added a  -A  switch that will cause the program to  append  rather than  overwrite  when saving settings.

This will append the command line settings to AutoCursor.conf but run with the command line settings.

Code: [Select]

sudo AutoCursor -hX -sY -A -S AutoCursor.conf
This will append the command line settings to AutoCursor.conf and then load AutoCursor.conf.

Code: [Select]

sudo AutoCursor -hX -sY -A -S AutoCursor.conf -L ~/.config/AutoCursor.conf
The updated extension has been posted.

[jazzbiker]

I added a  -A  switch that will cause the program to  append  rather than  overwrite  when saving settings.

Hi, Rich!

Thanks for update! Now AutoCursor became even more convenient!

[jazzbiker]

Hi, Rich!

Device properties (ID_INPUT_MOUSE, ID_INPUT_KEYBOARD, ID_INPUT_TOUCHPAD, ID_INPUT_TOUCHSCREEN) can be quered with

Code: [Select]

udevadm info -q property -p /sys/class/input/eventX | grep -q ID_INPUT_MOUSE

device names can be read with

Code: [Select]

cat /sys/class/input/eventX/device/name
and probably .conf file for AutoCursor can be produced according to this information.

[jazzbiker]

Hi, Rich and AutoCursor users!

        I'm attaching the script for auto-configuring AutoCursor. Its main purpose is nomadic use, of course, allowing avoid manual configuring on the newly visited machine. Script is very simple, no options, help or versions, the only command line parameter possible is the path to configuration file. Of course, it can be omitted in favour of default ~/.autocursor.conf. If devices found are already described in the existing configuration file, they are leaved unchanged. If some device is not yet present, the description with appropriate AutoCursor command (h or s) is appended.
        I have no touchscreen to test with TinyCore, so if anyone is able to test the script it will be interesting to know about the results, whether the "h" command will be assigned to it in the configuration file.

Regards!

[Rich]

Hi jazzbiker

... I have no touchscreen to test with TinyCore, so if anyone is able to test the script it will be interesting to know about the results, whether the "h" command will be assigned to it in the configuration file.

I ran it on the netbook I mentioned in reply#14:

Code: [Select]

s: "Asus TouchPad"
h: "Chicony HP Elite USB Keyboard"
h: "Broadcom Bluetooth Wireless  Keyboard                        "
s: "PixArt HP USB Optical Mouse"
h: "SYNA7508:00 06CB:11E5"The last entry is the touchscreen.

On another note, there are many ways to accomplish the same task under Linux. In that spirit, I'd like to offer you
an awk free version of your event loop in the attached file.

Awk can be a very powerful tool for quickly searching and manipulating text. I used it myself here:
http://forum.tinycorelinux.net/index.php/topic,24581.msg156588.html#msg156588
Since I've only dealt with awk 2 or 3 times, most of my time was spent Googling, reading, and trying to figure out why
it was doing what I told it to do, instead of what I wanted it to do.

My point is that while awk does do the job, in this case, ash is quite capable of doing it too. Using awk here sets the
bar higher than it needs to be for other people wanting to understand and/or modify your script.

[jazzbiker]

Hi, Rich!

Thanks for testing, even the simpliest scripts may sometimes play the tricks, caused by unattentiveness.
And thanks for the script example, but unfortunately it may fail. You were assuming, that this ID's are present in exclusive manner, but as documentation says, ID_INPUT_TOUCHPAD and ID_INPUT_TOUCHSCREEN may be accompanied with the ID_INPUT_MOUSE, and as we don't know anything about their order, ID_INPUT_MOUSE may appear earlier than ID_INPUT_TOUCHSCREEN and will cause wrong command. That's why I used awk.

Thanks again for AutoCursor!

[Rich]

Hi jazzbiker
After some searching I now see setting  ID_INPUT_MOUSE  was once the norm when  ID_INPUT_TOUCHPAD or
ID_INPUT_TOUCHSCREEN was set:

As shown above, udev itself already classifies the input devices with input_id. Existing flags are:

    ID_INPUT
       

    All input devices have this flag.

    ID_INPUT_MOUSE
       

    Touchscreens and tables have this flag as well, since by the type of events they can produce they act as a mouse.

    ID_INPUT_TABLET
       

    ID_INPUT_TOUCHSCREEN
       
 ----- Snip -----

Last edited 2010-04-13 and found here:
https://wiki.kubuntu.org/X/InputConfiguration#Device_classification

A more recent document from Feb 29 2016 states:

ID_INPUT
    If this property is set, the device is considered an input device. Any device with this property missing will be ignored, see Device type assignment via udev.
ID_INPUT_KEYBOARD, ID_INPUT_KEY, ID_INPUT_MOUSE, ID_INPUT_TOUCHPAD, ID_INPUT_TOUCHSCREEN, ID_INPUT_TABLET, ID_INPUT_JOYSTICK, ID_INPUT_ACCELEROMETER
    If any of the above is set, libinput initializes the device as the given type, see Device type assignment via udev. Note that for historical reasons more than one of these may be set at any time, libinput will select only one of these to determine the device type. To ensure libinput selects the correct device type, only set one of them.

 ----- Snip -----

The usual error handling applies within libinput and a device type label does not guarantee that the device is initialized by libinput. If a device fails to meet the requirements for a device type (e.g. a keyboard labelled as touchpad) the device will not be available through libinput.

Only one device type should be set per device at a type, though libinput can handle some combinations for historical reasons.

Below is an example udev rule to remove an ID_INPUT_TOUCHPAD setting and change it into an ID_INPUT_TABLET setting. This rule would apply for a device with the vendor/model ID of 012a/034b.

Code: [Select]

ACTION=="add|change", KERNEL=="event[0-9]*", ENV{ID_VENDOR_ID}=="012a", \
ENV{ID_MODEL_ID}=="034b", ENV{ID_INPUT_TOUCHPAD}="", ENV{ID_INPUT_TABLET}="1"
 ----- Snip -----

So the rule is only one device type is supposed to be set, but certain errors will be tolerated and worked around.

[jazzbiker]

Hi, Rich!

Yes, I saw both pages, and noticed, that worse case is an outdated one. Then I decided to check, what's going on right now. And on ASUS-1215B running Lubuntu 16.04 I've got:

Code: [Select]

andrey@andrey-1215B:~$ uname -a
Linux andrey-1215B 4.15.0-133-generic #137~16.04.1-Ubuntu SMP Fri Jan 15 02:55:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
andrey@andrey-1215B:~$ cat /sys/class/input/event9/device/name
SynPS/2 Synaptics TouchPad
andrey@andrey-1215B:~$ udevadm info -q property -p /sys/class/input/event9
DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
DEVNAME=/dev/input/event9
DEVPATH=/devices/platform/i8042/serio1/input/input7/event9
ID_INPUT=1
ID_INPUT_HEIGHT_MM=34
ID_INPUT_TOUCHPAD=1
ID_INPUT_TOUCHSCREEN=1
ID_INPUT_WIDTH_MM=64
ID_PATH=platform-i8042-serio-1
ID_PATH_TAG=platform-i8042-serio-1
ID_SERIAL=noserial
LIBINPUT_DEVICE_GROUP=11/2/7/1b1:isa0060/serio1
LIBINPUT_MODEL_JUMPING_SEMI_MT=1
LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1
MAJOR=13
MINOR=73
SUBSYSTEM=input
USEC_INITIALIZED=5652584

Not bad, yeah?

Of course, TinyCore is well known to be the best distribution in our Univrse and gave me on the same box:

Code: [Select]

tc@box:~$ uname -a
Linux box 4.19.10-tinycore64 #1999 SMP Tue Dec 18 15:18:54 UTC 2018 x86_64 GNU/Linux
tc@box:~$ cat /sys/class/input/event8/device/name
SynPS/2 Synaptics TouchPad
tc@box:~$ udevadm info -q property -p /sys/class/input/event8
DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
DEVNAME=/dev/input/event8
DEVPATH=/devices/platform/i8042/serio1/input/input6/event8
ID_INPUT=1
ID_INPUT_TOUCHPAD=1
ID_PATH=platform-i8042-serio-1
ID_PATH_TAG=platform-i8042-serio-1
ID_SERIAL=noserial
MAJOR=13
MINOR=72
SUBSYSTEM=input
USEC_INITIALIZED=4032823

awk is already in the busybox, so I used it.

I think we can use this flags wiith care, and manual corrections surely must have higher priority over the proposed by any auto-detections for this use case.

[Rich]

Hi jazzbiker

... Not bad, yeah? ...

Yeah, but I did notice this:

Code: [Select]

----- Snip -----

ID_INPUT_TOUCHPAD=1
ID_INPUT_TOUCHSCREEN=1

 ----- Snip -----

LIBINPUT_DEVICE_GROUP=11/2/7/1b1:isa0060/serio1
LIBINPUT_MODEL_JUMPING_SEMI_MT=1
LIBINPUT_MODEL_SYNAPTICS_SERIAL_TOUCHPAD=1

 ----- Snip -----

So this breaks the rules by selecting 2 devices.
Then it appears to break them again because  ID_INPUT_MOUSE  isn't one of them.
Yet  libinput  still figures out the correct device.

[jazzbiker]

Hi, Rich!

Does to get more (the most?) reliable device classifier we need to ask libinput?
Then the sequence became a little bit longer.
1. Get list of events
2. If device is keyboard, assign 'h' cmd and go on. else
3. If device is of some kind graphical manipulator (including tablets, joystick and even accelerators?) then capture its name
4. Associate this name with X device id, using "xinput list"
5. Capture device properties
6. Determine device role depending on "absolute" ('h' command) or "relative" ('s' command) property presence.

Such way may appear to be unambiguous. What's Your opinion?

[Rich]

Hi jazzbiker

Does to get more (the most?) reliable device classifier we need to ask libinput? ...

I don't think so. I would suggest this might be a Lubuntu issue. If you look at your reply #23, you'll see Tinycore listed
only the correct device. Maybe Lubuntu needs a udev rule (see reply #22) similar to:

Code: [Select]

ACTION=="change", KERNEL=="event[0-9]*", ENV{ID_VENDOR_ID}=="0002", \
ENV{ID_MODEL_ID}=="0007", ENV{ID_INPUT_TOUCHSCREEN}=""
Your script, because it looks at touchpad before touchscreen, would return the correct result.

[Rich]

Hi jazzbiker
The programs  usage  page did not list all of the command line switches. This has been corrected,
The updated extension has been posted.

[jazzbiker]

Hi, Rich!

Thanks for the update! I didn't tried yet AutoCursor under Lubuntu, but I hope it will run without problems under another Linuxes.

[jazzbiker]

Hi, Rich!

You didn't submitted AutoCursor for TC12, so I copied tcz from TC10 tce directory. libXfixes was last updated 2017/02/20, I think this is reliable. Am I right?