Change to allow running on its own

[brunoais]

Solves #2

I'm open for discussion but I really want this kind of features for myself as I use the xfce desktop.

[Matombo]

I still don't think it's a good idea to toggle the touchpad independend of what the DE thinks the touchpad state is. I think it will confuse people, which then will lead to false bug reports.

But, without having checked it for myself yet, since xfce is gnome based, doesn't it also use dconf? If yes, I don't think it should be too hard creating a setup-xfce by copying and altering the setup-gnome. Do you want to look into it?

[brunoais]

I still don't think it's a good idea to toggle the touchpad independend of what the DE thinks the touchpad state is. I think it will confuse people, which then will lead to false bug reports.

That can only happen when the program is run as a standalone (instead of daemon). As a standalone, the program needs to be executed by some other program. Most likely, that other program would also change the DE's touchpad state in the process.
If a user only sets so this program is called at certain times without including a switching process for the DE itself, I'm quite sure that such user would be enough tech savvy to understand and not complain.
For a friend, I would make a bash script including:

ID=$(xinput list | grep -Eo 'Touch[pP]ad\s*id\=[0-9]{1,2}' | grep -Eo '[0-9]{1,2}')
STATE=$(xinput list-props $ID|grep 'Device Enabled'|awk '{print $4}')

if [[ "$STATE" == "0" ]] ; then
    xinput enable $ID
    tuxedo-touchpad-switch --set on
    echo "Touchpad enabled."
else
    xinput disable $ID
    tuxedo-touchpad-switch --set off
    echo "Touchpad disabled."
fi

In this example, the bash script keeps them in sync.

Do note that if the program is already running as a daemon, it refuses to run again (ensured by the use of the pid file in /run)

Do you think otherwise?

since xfce is gnome based,

Is it? I know some elements are shared but I wonder if it really is gnome based :)

doesn't it also use dconf? [...] Do you want to look into it?

I'll look into it. Maybe I'll figure out a way to detect if dconf exists instead of using a failure-prone environment variable.

[brunoais]

I checked with xfce. The status of the touchpad devices (1 for physical clicking and 1 for the pad) is stored in xfconf and not in dconf. I think they are similar in intention and xfconf has monitoring. I just have no idea about xfconf's API and I would need to study it...
I'll do some more research on whether these can be detected and chosen as needed or whether the code can just register to all and let itself be called by them.
Currently, with xfce, if I run the gnome daemon mode, it appears to work but it isn't working at all.

[Matombo]

ID=$(xinput list | grep -Eo 'Touch[pP]ad\s*id\=[0-9]{1,2}' | grep -Eo '[0-9]{1,2}')
STATE=$(xinput list-props $ID|grep 'Device Enabled'|awk '{print $4}')

if [[ "$STATE" == "0" ]] ; then
    xinput enable $ID
    tuxedo-touchpad-switch --set on
    echo "Touchpad enabled."
else
    xinput disable $ID
    tuxedo-touchpad-switch --set off
    echo "Touchpad disabled."
fi

In this example, the bash script keeps them in sync.

2 issues with this Script: It might get out of sync when you switch user from the lockscreen and gnome for example does not disable the events node (like xinput disable does) but only sets the touch events of the events node on ignore (can also be done with xinput).

Also the setting menu might not update like this on every DE.

As I read my last reply again I realised that It might be mssunderstood: I don't think a standalone toggle programm is a bad idea. I just don't think it should be the same programm as this daemon, as the goal of this deamon is passive driver only that the user does not need to think about.

[brunoais]

As I read my last reply again I realised that It might be mssunderstood: I don't think a standalone toggle programm is a bad idea. I just don't think it should be the same programm as this daemon, as the goal of this deamon is passive driver only that the user does not need to think about.

Oh! I see. May I make a 2nd executable in this project for the standalone program, then?
tuxedo-touchpad-switch-ctl.cpp for example.

[brunoais]

@Matombo , I finally got the time and finally updated the code with the split between the daemon and the cli. Check if it looks good please.
Unfortunately, I cannot test the daemon, so I will have to trust you to do that test.
The cli appears to work as intended as it worked with my manual tests.

[mhx]

Thanks @brunoais and @Matombo! I just tested @brunoais' latest update and the CLI version works nicely for me. I'm running OpenBox with a bunch of Xfce components (the setup can hardly be called a desktop environment) and this is just what I was looking for.

[brunoais]

@mhx Does the touchpad toggle button work for you? In my system, it's detected as CTRL+SUPER a combination that doesn't exist in the keyboard (but I can assign to things), btw. The SUPER key is detected as SUPER_L

[mhx]

@mhx Does the touchpad toggle button work for you?

Yes, works perfectly (albeit after a bit of head-scratching), both with the button area on the touchpad itself and Fn+F9.

I've put this in my .xmodmaprc (which gets loaded by .xinitrc):

keycode 93 = XF86TouchpadToggle

I've enabled the touchpad toggle button with:

synclient LTCornerButton=1

Last but not least, I've added this to openbox's rc.xml:

    <keybind key="W-C-XF86TouchpadToggle">
      <action name="Execute">
        <command>tuxedo-touchpad-switch-cli -t</command>
      </action>
    </keybind>

So the whole thing only works under X, but that's good enough for me.

[brunoais]

In this last force-push I changed "By default, the executable has setuid permissions" because I decided not to have setuid, at least, yet.

[mhx]

FWIW, the xmodmap change is unnecessary (in fact, it even makes things very unpredictable) if the tuxedo_keyboard / tuxedo_io kernel modules are loaded. Also, if these modules are loaded, the XF86TouchpadToggle is delivered without any modifiers.

[brunoais]

@Matombo Any updates?

[Matombo]

Sorry it took me some time to answer.

Mostly because I don't want to reject your effords, but still it would change the KISS target of this repository. Even when there are 2 binaries now. Also I must optimize my long term maintanace tasks to not be distracted from new devices and features.

So at the end of the day, while I really appreciate your effords, I will not accept the MR. I'm sorry.

But feel free to fork the repository under the gpl and release your own version.

[brunoais]

@Matombo May I create a PR for other things I did that helped doing the -cli version but were not strictly needed?
E.g.

1. Many of the changes to README.md
2. All of touchpad-control.cpp and some consequences of it.

?

[Matombo]

TBH for the time being i consider the code "clean enough", so a heads-up: the code review for that patch will have a very low priority.

Unless ofcourse you found an bug that needs fixing.

When you create a new merge requests it will be helpfull when you split it up in functional units like:

• Better README
• Replacing integer literals by easier to understand defines
• etc.

[Matombo]

For reference: I still hope that someone comes up with an idea for a proper upstream fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/558
I would be glad to help in its implementation.