Bug 427

Confirmed.

This bug needs the still-to-be-written TDE udev interface library to be properly fixed.  See http://trinitydesktop.org/wiki/bin/view/Developers/TUComputerAPI for the specification.

In short, TDE does not handle device hotplugging in a sane manner.  Trying to
hack around the problem will not help and risks introducing more bugs; the best
and safest solution is to implement true systemwide hotplug support for TDE via
the above library specification.

Here is an example to replicate a version of this bug:

With one user account, ensure "Turn on" is selected. With a second user account, ensure either "Turn off" or "Leave unchanged" is selected.

Boot the system to the command line or to graphical mode with TDM. Enable Num Lock and confirm the LED is on.

Login as the first user. After the desktop is loaded, confirm the keyboard Num Lock LED is on. Remain logged in.

Toggle to TDM or to a second console and login as the second user. After the desktop is loaded, confirm the LED is off.

Toggle to the first user's desktop (typically Ctrl-Alt-F7). The LED will be off but the Num Lock state is correct. Validate this by pressing any key in the numeric keypad. Also press the Num Lock key twice and notice the LED is on after the second press, which means the Num Lock state was already correct despite the LED being off.

X always disables Num Lock rather than leaving unchanged. This can be verified when logging in from a console and using startx by watching the LED toggle off and then on again in Trinity. Likewise with TDM. There is a tdmrc option to set Num Lock on. Yet after logging in with TDM the LED will toggle off before toggling back on for the user's desktop.

The root problem with Num Lock issues is X. The numlockx package is a work-around to a flawed X design and often recommended as a solution, but can't be guaranteed to be installed on any system. Although kcmmisc.cpp has Num Lock support and some numlockx code, I don't see anything to set/confirm the LED status. In this example that is the only bug.

This should be fixed for HAL based systems as well as with the new TDEHW libs.

This report is tagged as Trivial, but is there hope for a remedy now that much of tdehwlib is in place?

As reported, often the Num Lock state is correct but only the LED fails to remain correct. For example, toggle to a console (not xterm) and then return to X (usually Alt-F7) and the LED toggles off. Pressing the Num Lock key twice restores the LED state, but pressing twice indicates the Num Lock state itself remains unchanged.

Seems that every time the Trinity desktop receives focus from another console or another Trinity session, tdehwlib should automatically check the state of Num Lock and then verify the LED has the same state.

This irritating bug should finally be fixed in GIT hash f9c0d0e.  There was no clean way to repair this (due to myriad Xorg failures and bugs in this area), so I settled on a small daemon that keeps the keyboard indicator lights synchronized with the internal Xorg Xkb state.

If you do not use tdm, you will need to load the tdekbdledsync daemon in the background via sudo from within your running TDE session.

Let me know what you think!

What is the correct command line syntax to load the tdekbdledsync daemon? (I don't use TDM and I imagine an autostart script is needed.)

Second, this daemon does not appear in the list of Load-on-demand or Startup services in kcontrol?

Third, why is the extra effort needed when not using TDM?

Fourth, rather than fiddle with su/sudo, can the binary file be set UID?

I want to test --- just need to know what I am doing.

(In reply to comment #6)
> What is the correct command line syntax to load the tdekbdledsync daemon? (I
> don't use TDM and I imagine an autostart script is needed.)

sudo tdekbdledsync &

> Second, this daemon does not appear in the list of Load-on-demand or Startup
> services in kcontrol?

It's not a TDE daemon, it's a very small standard process that uses no TDE/TQt code for security/bloat reasons.

> Third, why is the extra effort needed when not using TDM?

TDM launches the daemon on X start.  Because TDM runs as root, it can do this, whereas a user would need to use sudo to launch the daemon.

> Fourth, rather than fiddle with su/sudo, can the binary file be set UID?

Probably; I haven't tried this.  Good idea!  Can you test and report back? :-)

> I want to test --- just need to know what I am doing.

You'll know it works if you enable Numlock in your TDE session, switch to a text-mode virtual terminal, disable Numlock there, then switch back to your TDE session VT.  In my testing without the daemon this invariably led to Numlock LED off with the number pad working.  If the daemon is working, you will instead see Numlock LED on and the number pad working.

Here is what I see:

Previously I had built tdebase with -DBUILD_TDEKBDLEDSYNC=ON.

Opening konsole and setting tdekbdledsync set UID works fine. I presume a script/desktop file in the autostart directory will suffice, but I haven't yet tested.

Is there a way to have the binary file automatically compile chmod 4755? If not then we'll have to force the issue in the build script, which I am going to do for now.

Normally I don't use a login manager and boot to runlevel 3 to log in at the command line. I set Num Lock on in my rc.local for all consoles.

Toggling from my user's desktop with Ctrl-Alt-F2 to console 2, which has Num Lock already set, and then back to my desktop with Ctrl-Alt-F7, results in the LED blinking twice and then remaining on to match the actual Num Lock state. The patch has succeeded.

Repeating the same process but while in console 2 manually pressing the Num Lock key to disable Num Lock and then returning to the desktop with Ctrl-Alt-F7, results in the LED again being on to match the actual state. The twist is when I immediately toggle to console 2 the LED remains on despite me having manually disabled Num Lock. The LED should be off when I return to console 2. In console 2 the LED does not match the actual state because typing with the number keypad does not display the expected results. The LED not reflecting the actual state in console 2 is repeatable.

The patch always works correctly with respect to the user's desktop. We probably should remedy the second test case as I can envision multiple users on the same machine where one wants Num Lock and the other doesn't.

I can't do anything about the text mode console; that is a different bug not related to the new daemon. :-)  In a nutshell neither the console nor X11 bother to make sure the Numlock LED is properly set; I can fix the problem in X11 (via the new daemon), but I can't fix the problem at the console.

If you fire up a second TDE session (both sessions running a separate instance of the new daemon), and set Numlock in one but not the other, you will note that toggling between the two X11 (TDE) sessions also sets the Numlock LED to the proper state for that session.

The blinking is unavoidable, it is caused by X11 (or the kernel, not sure which!) attempting to set the LED to the *incorrect* state.  Fun, eh? :-)

(In reply to comment #8)
> Is there a way to have the binary file automatically compile chmod 4755?

Didn't see this before I posted my comment above.  Yes, this can be done.  yes, this should be done. :-)  I will try to do it soon.

The mometary blinking LED does not bother me. I only mentioned to report what I saw. :-)

I agree the second test is not a Trinity issue. The real problem has ALWAYS been the anal X developers who insist on disabling Num Lock rather than ignoring so X starts however the user wants.

I'll rebuild and test when the automatic chmod 4755 is patched.

Otherwise, nice job and thanks! :-)

SUID set in GIT hash 5a7a258.

If there are no more issues, please mark this report RESOLVED FIXED. :-)

Thanks for reporting!

I rebuilt tdebase with commit 5a7a258. I wrote a simple shell script and a *.desktop file for my user's Trinity autostart directory. I am not noticing any problems with anything as previously discussed.

As requested I'm tagging this report as resolved. Thanks for the fix. :-)