Michele Calgaro via tde-users wrote:

another temporary way is to use kkbswitch, which allows to set TDE shortcut for specific layout, although there is no keyboard shortcut for "cycling through" layouts.

I use CTRL+ALT+<Right Arrow>, because the CTRL+ALT+k does not work in cyrillic lay out.

Interestingly after getting latest changes installed I do not experience any issues - CTRL+ALT+<Right Arrow> works as before xkbd is disabled here

Hi Michele,

thank you for your response

Hi Peter

...

after upgrading to R14.1.0 I miss the old way of switching between keyboard layouts with Ctrl+Alt+K.

It is something we unfortunately missed at first and we have already identified this to be a problem. Slavek and I have been discussing the same problem, so we will see how we can put back a way to let the user choose a fully custom TDE shortcut (like Ctrl+Alt+K).

It would be very nice step to revert back this functionality :-)

...

Is there any way to revert back to the original keyboard shortcut for switching the keyboard layout?

For the time being, the best you could probably do is to have a small script to switch the keyboard layout and use an Input action tighten to Ctrl+Alt+K to run the script. You can use dcop to get the list of available layouts, the current layout and set a new layout, so it should be relatively straightforward to come up with something working

Elegant solution. Thanks a lot.

...

In addition, the keyboard model setting apparently stopped working, in my case "Dell Latitude laptop" - some functions no longer work, e.g. Fn+F1 (for sleep) or Fn+F5 (for touchpad toggle) or Fn+Arrows (for brightness level). Everything worked for over a decade before the upgrade.

Uhm.... there isn't any specific change that would make this stop working. The keyboard sends keycode and TDE use them. Maybe you are missing some package after the upgrade? Not sure about your distro, but look for example for something with kmilo in its name.

I have installed kmilo-trinity (4:14.1.0-0debian12.0.0+0~a). It may be possible that the fault is probably somewhere else. I will look for a solution at the OS level.

Many thanks for your response. Have a nice day :-)

Cheers Michele

...

I have installed kmilo-trinity (4:14.1.0-0debian12.0.0+0~a). It may be possible that the fault is probably somewhere else. I will look for a solution at the OS level.

Ok, after your investigation, please let us know if you can trace this back to a TDE bug. Cheers Michele

I started an older saved installation of TDE R14.0 (Debian 9, kernel 4.9.0) and here the special Fn key combination works perfectly ("XF86Sleep" puts the laptop to sleep, "XF86MonBrightnessUp/Down" changes the display brightness, etc.)

On the latest TDE 14.1 (Debian 12, kernel 6.1.0) in kcontrol > Peripherals > Laptop Battery > Power Control ... I have the following message: "Your computer seems to have a partial ACPI installation. ACPI was probably enabled, but some of the sub-options were not - you need to enable at least 'AC Adaptor' and 'Control Method Battery' and then rebuild your kernel."

So I assume that the problem will be somewhere on the side of missing ACPI support or kernel modules. However, putting the laptop to sleep using the context menu from TDEPowersave works without a problem, as does the detection of the AC adapter or battery status... So I assume that ACPI support should be sufficient.

On an older installation of TDE 14.0 (Debian 9), the mentioned controls in kcontrol are available and without any error message.

I don't have any special ACPI programs or utilities for the older installation, and it's practically a standard installation of Debian 9 + TDE 14.0. In the case of a newer Debian 12 + TDE 14.1 installation, this is also a fairly standard installation. I checked the installed modules (older versus new installation) and they are pretty much the same everywhere.

Where else could there be a problem?

Many thanks -- Petr Palacky

Hi Michele,

since I want to keep my older version installation intact, I installed on another disk drive the stock Debian 12 with the previous version of TDE 14.0.13. On this clean installation, I tried Fn+F1 (XF86Sleep) and the function worked perfectly - the laptop went to sleep. The same for XF86MonBrightnessUp/Down.

I then upgraded to the latest version of TDE 14.1.0 and rebooted just to be sure. From now on XF86Sleep nor XF86MonBrightnessUp/Down initiation does not work. The only thing that has changed on this setup is the TDE upgrade from 14.0.13 to 14.1.0.

In conclusion - I assume that this test shows that the problem must be somewhere on the TDE side. Maybe the binding of some XF86* events is disconnected? Hard to say for me ...

Cheers -- Petr Palacky

Dne st 10. května 2023 13:38:30 Michele Calgaro via tde-users napsal(a):

...

I don't have any special ACPI programs or utilities for the older installation, and it's practically a standard installation of Debian 9 + TDE 14.0. In the case of a newer Debian 12 + TDE 14.1 installation, this is also a fairly standard installation. I checked the installed modules (older versus new installation) and they are pretty much the same everywhere.

Hi Petr, I don't know if it is something easily feasible for you, but a good test to determine whether it is a kernel issue or a TDE issue would be to update the old installation to R14.1.0 but keeping the existing 4.9 kernel. If the problem shows up on R14.1.0 with the old kernel, it is definitely something in TDE. If R14.1.0 works fine, it is more likely not a TDE issue. Alternatively (or as additional test), running R14.0.13 on the new Debian 12 would also help providing further info.

I don't have a Dell with TDE, but usually brightness and volume controls work fine, so I would be surprised if they didn't on a Dell. Until 7 years ago I had a Dell and they were definitely working back then (I was running R14.1.0-dev) although it was long ago.

Cheers Michele

Hi Michele,

yes, KMilo service is runnig.

Cheers -- Petr Palacky

Outgoing message is virus free because we are using Linux.

Debian GNU/Linux 12 (bookworm), kernel 6.1.0-2-amd64.

Dne čt 11. května 2023 02:32:31 Michele Calgaro via tde-users napsal(a):

On 2023/05/10 10:01 PM, Petr Palacký via tde-users wrote:

...

In conclusion - I assume that this test shows that the problem must be somewhere on the TDE side. Maybe the binding of some XF86* events is disconnected? Hard to say for me ..

Hi Petr, yup, that seems the logical conclusion. Most of those special keys are handled in kmilo. Can you check that KMilo is running? Go to TCC -> TDE components -> Service manager -> Startup services and check kmilo. If it is not running, start it up and see if things work again.

Cheers Michele

Hi Michele,

Fn+F1 (for sleep): ------------------------------------------------------------------------------------------------------------------- KeyPress event, serial 30, synthetic NO, window 0x5200001, root 0x288, subw 0x0, time 136987843, (46,99), root:(1463,148), state 0x10, keycode 150 (keysym 0x1008ff2f, XF86Sleep), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x5200001, root 0x288, subw 0x0, time 136987843, (46,99), root:(1463,148), state 0x10, keycode 150 (keysym 0x1008ff2f, XF86Sleep), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

Fn+F5 (for touchapd toggle): ------------------------------------------------------------------------------------------------------------------- KeyPress event, serial 40, synthetic NO, window 0x5200001, root 0x288, subw 0x0, time 137208989, (162,65), root:(1579,114), state 0x10, keycode 199 (keysym 0x1008ffa9, XF86TouchpadToggle), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x5200001, root 0x288, subw 0x0, time 137208989, (162,65), root:(1579,114), state 0x10, keycode 199 (keysym 0x1008ffa9, XF86TouchpadToggle), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

Fn+ArrowUp (for brightness level up): ------------------------------------------------------------------------------------------------------------------- KeyRelease event, serial 37, synthetic NO, window 0x5200001, root 0x288, subw 0x0, time 137095923, (107,143), root:(1524,192), state 0x10, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

Fn+ArrowDown (for brightness level down): ------------------------------------------------------------------------------------------------------------------- KeyRelease event, serial 39, synthetic NO, window 0x5200001, root 0x288, subw 0x0, time 137144295, (-1292,557), root:(125,606), state 0x10, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

Cheers -- Petr Palacky

Dne čt 11. května 2023 08:54:43 Michele Calgaro via tde-users napsal(a):

On 2023/05/11 02:55 PM, Petr Palacký wrote:

...

Hi Michele,

yes, KMilo service is runnig.

Hi Petr, ok, thanks for the info. Are you able to use xev to see what key codes are sent when you use those Fn keys? Cheers Michele

Hi Michele,

tdepowersave is runnig and I am able to initiate sleep or suspend via context menu. But in settings I am not able to set automatic brightness - this section tell me that an automatic brightness is not supported.

Command `dcop tdepowersave tdepowersaveIface do_brightnessDown 90` return "false". Command dcop tdepowersave tdepowersaveIface brightnessGet` return "-1".

Other command seems look OK - eg: `dcop tdepowersave tdepowersaveIface do_suspendToRAM`

S pozdravem -- Petr Palacky

Outgoing message is virus free because we are using Linux.

Debian GNU/Linux 12 (bookworm), kernel 6.1.0-2-amd64.

Dne čt 11. května 2023 11:25:18 Michele Calgaro via tde-users napsal(a):

On 2023/05/11 04:49 PM, Petr Palacký wrote:

...

Hi Michele,

Fn+F1 (for sleep):

Hi Petr, the key events seem ok. I looked into the code. Do you have tdepowersave installed and running? For example brightness changes are handled through tdepowersave. If tdepowersave was not running, please run and try again. If tdepowersave was already running, can you try using dcop to call some of the tdepowersave methods and see if they work for you?

Cheers Michele

Hi Michele,

So everything is completely different in the end.

I've done a bunch of tests and installs and the only problem is the Nvidia 390 legacy drivers. If I use the nouveau drivers on my existing installation, the brightness can be controlled without any problems, but when I use the official nvidia (390 legacy) drivers, the brightness cannot be controlled.

So it's definitely not a TDE problem. It's a problem of nvidia drivers.

I apologize for the confusion. I didn't think of this at all during the inquiry.

Cheers -- Petr Palacky

Dne čt 11. května 2023 14:57:20 Michele Calgaro via tde-users napsal(a):

On 2023/05/11 08:59 PM, Petr Palacký wrote:

...

tdepowersave is runnig and I am able to initiate sleep or suspend via context menu. But in settings I am not able to set automatic brightness - this section tell me that an automatic brightness is not supported.

Command `dcop tdepowersave tdepowersaveIface do_brightnessDown 90` return "false". Command dcop tdepowersave tdepowersaveIface brightnessGet` return "-1".

Other command seems look OK - eg: `dcop tdepowersave tdepowersaveIface do_suspendToRAM`

S pozdravem

Ok, this sounds like a regression. Two things:

1. could you please create an issue report on TGW?

Use this repository for the issue: https://mirror.git.trinitydesktop.org/gitea/TDE/tdepowersave Instructions here: https://wiki.trinitydesktop.org/TDE_Gitea_Workspace#To_report_bugs_and_sugg est_enhancements We can then continue the discussion there, it's a better place for this kind of things.

2. I will probably need some more info as I look into this. If I need to

test a patch, are you able to build tdepowersave eventually? If you are not familiar with that, I will point you to a set of scripts that will make building it relatively simple. All you will need is enough disk space. This may be of big help to troubleshoot this issue.

Cheers Michele

Hi all,

for everyone who has the same problem with setting the display brightness with the nvidia driver (in my case "390 legacy"), I found the following solution to "revive" the display brightness:

In "/etc/default/grub" add "acpi_backlight=vendor" and/or "nvidia.NVreg_EnableBacklightHandler=1" to the variable GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet nvidia.NVreg_EnableBacklightHandler=1 acpi_backlight=vendor".

... and reboot. With this setting, controlling the display brightness using TDE and multimedia (or Fn combination) keys should work (works for me).

Cheers -- Petr Palacky

On Friday 12 of May 2023 09:58:30 Petr Palacký via tde-users wrote:

...

Hi Michele,

So everything is completely different in the end.

I've done a bunch of tests and installs and the only problem is the Nvidia 390 legacy drivers. If I use the nouveau drivers on my existing installation, the brightness can be controlled without any problems, but when I use the official nvidia (390 legacy) drivers, the brightness cannot be controlled.

So it's definitely not a TDE problem. It's a problem of nvidia drivers.

I apologize for the confusion. I didn't think of this at all during the inquiry.

Cheers

Petr Palacky

Dne čt 11. května 2023 14:57:20 Michele Calgaro via tde-users napsal(a):

...

On 2023/05/11 08:59 PM, Petr Palacký wrote:

...

tdepowersave is runnig and I am able to initiate sleep or suspend via context menu. But in settings I am not able to set automatic brightness - this section tell me that an automatic brightness is not supported.

Command `dcop tdepowersave tdepowersaveIface do_brightnessDown 90` return "false". Command dcop tdepowersave tdepowersaveIface brightnessGet` return "-1".

Other command seems look OK - eg: `dcop tdepowersave tdepowersaveIface do_suspendToRAM`

S pozdravem

Ok, this sounds like a regression. Two things:

1. could you please create an issue report on TGW?

Use this repository for the issue: https://mirror.git.trinitydesktop.org/gitea/TDE/tdepowersave Instructions here: https://wiki.trinitydesktop.org/TDE_Gitea_Workspace#To_report_bugs_and _sugg est_enhancements We can then continue the discussion there, it's a better place for this kind of things.

2. I will probably need some more info as I look into this. If I need

to test a patch, are you able to build tdepowersave eventually? If you are not familiar with that, I will point you to a set of scripts that will make building it relatively simple. All you will need is enough disk space. This may be of big help to troubleshoot this issue.

Cheers Michele

---

The brightness control is performed via sysfs - ie brightness device in /sys/devices/. If the driver does not publish this standard method, this is the cause of the problem.

The same way is also for suspend and hibernation, as well as the response to the closing of the lid - everything goes through sysfs.

Cheers

On 2023/05/12 04:58 PM, Petr Palacký wrote:

So it's definitely not a TDE problem. It's a problem of nvidia drivers.

I apologize for the confusion. I didn't think of this at all during the inquiry.

No worries Petr, we troubleshooted it step by step and in the end it was not a TDE issue :-) Reporting problems and bugs helps in making TDE better, so feel free to bring up more issues if you run into them. Cheers Michele

Michele Calgaro via tde-users wrote:

...

In addition, the keyboard model setting apparently stopped working, in my case "Dell Latitude laptop" - some functions no longer work, e.g. Fn+F1 (for sleep) or Fn+F5 (for touchpad toggle) or Fn+Arrows (for brightness level). Everything worked for over a decade before the upgrade.

Uhm.... there isn't any specific change that would make this stop working. The keyboard sends keycode and TDE use them. Maybe you are missing some package after the upgrade? Not sure about your distro, but look for example for something with kmilo in its name.

Hi Michele, since it automagically switched to the new functionality, the whole layout switching stops working. I still don't know why, but it is annoying. I work around this as following. Whenever it stops working, I disable/enable the keyboard layouts (I guess the applets backend gets restarted). As you were overseeing the changes, can you advise how and where to debug?

Perhaps Petr can try next time and tell us if this is also the case on his end with the multimedia keys.

Michele Calgaro via tde-users wrote:

Hi Emanoil, can you be more specific than just "stop working"? As far as I remember you are using a script to set a shortcut for layout switch. First thing I would do is to not run kxkb and see if the problem happens even without kxkb. If the problem does not happen without kxkb, then we will need to look into the code. It could be possible that when you open the dialog and play around and then press ok, kxkb overwrites the old options and therefore the whole things "stop working".

Hi Michele, I wish I could be more specific, but for now it is just heads up, because it appeared yesterday after I started the configuration and pressed OK. So for now I do not know much more as of why. As of how, I can say that I do not use scripts. I had to customize the shortcut combination before from default CTR+ALT+k to CTRL+ALT+<right arrow>, because the "k" combination was not working when switched to Cyrillic keyboard.

I also never used kxkb consciously - I now see it is spawned by tdeinit S 16:24 0:00 kxkb [tdeinit] I do not know if it was spawned before, but I definitely did not logout/login since it started.

The problem is that since yesterday it stops switching the layouts now and then, without any intervention from my side. For example, I check mail or do something else i.e. browser or command line stuff, I then switch to Signal (which I run with ksystraycmd) and I try changing layout so that I can write in a another language, but it is not working. When I click the icon with the mouse, the labels change, but the key layout stays to what was before (en or de). For example now it works every where, but what could I do to find out why it stops working next time?

Uff, I am thinking of reverting back to before those patches, but it would mean to rebuild a lot because it is in tdelibs.

On 2023/05/13 06:13 AM, deloptes via tde-users wrote:

The problem is that since yesterday it stops switching the layouts now and then, without any intervention from my side. For example, I check mail or do something else i.e. browser or command line stuff, I then switch to Signal (which I run with ksystraycmd) and I try changing layout so that I can write in a another language, but it is not working. When I click the icon with the mouse, the labels change, but the key layout stays to what was before (en or de). For example now it works every where, but what could I do to find out why it stops working next time?

Hi Emanoil, thanks for the feedback. Actually what you described resembles a lot the experience I had with R14.0.x code, when sometimes the layout was not switching correctly using kxkb. With the new code in R14.1.0 I have not experienced that. I think the first step is to collect more info. When the problem shows up again, use setxkbmap to see what the current settings/options are. Try changing the language and use setxkbmap to check whether the changes took place or not. Also double check the layout switching policy in TCC to see if you are doing changes globally or by app or by window.

Cheers Michele

Michele Calgaro via tde-users wrote:

I think the first step is to collect more info. When the problem shows up again, use setxkbmap to see what the current settings/options are. Try changing the language and use setxkbmap to check whether the changes took place or not.

I now ran setxkbmap without any argument and then tried ALT+Shift, but it did not change the layout. I ran it with -query and -print setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+de+inet(evdev)" }; xkb_geometry { include "pc(pc105)" }; }; and while not switching between layouts (the icon is not changing and setxkbmap output stays the same)

disable+enable the keyboard layouts and it works again. Now looking like this

setxkbmap -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+de(nodeadkeys)+us:2+bg(phonetic):3+ru(phonetic):4+inet(evdev)+group(alt_shift_toggle)" }; xkb_geometry { include "pc(pc105)" }; };

I hope it helps to find a solution. BR

PS: I did not reboot, logout/login or whatever

On 2023/05/17 07:48 PM, deloptes via tde-users wrote:

Michele Calgaro via tde-users wrote:

...

Hi Emanoil, thanks for the feedback. Actually what you described resembles a lot the experience I had with R14.0.x code, when sometimes the layout was not switching correctly using kxkb. With the new code in R14.1.0 I have not experienced that. I think the first step is to collect more info. When the problem shows up again, use setxkbmap to see what the current settings/options are. Try changing the language and use setxkbmap to check whether the changes took place or not. Also double check the layout switching policy in TCC to see if you are doing changes globally or by app or by window.

Hi Michele, I think I now know why it is happening. I have a USB KVM Switch and use it to operate another PC. Whenever I switch back to TDE the keyboard is not working - tested few times and it is reproducible. What next?

Hi Emanoil, do you get the same events (using xev) before and after the KVM switch? That is, is TDE receiving the correct key events in both cases or not? Based on the answer let's see what to do next. And do "setxkbmap -query" and "setxkbmap -print" give the same output before and after the switch?

Also, was it working fine with R14.0.13? Cheers Michele

I do not think so - when not working it is Meta_L+Shift_L and when working it is Alt_L+Shift_L + some ISO_Next_Group

...

That is, is TDE receiving the correct key events in both cases or not? Based on the answer let's see what to do next. And do "setxkbmap -query" and "setxkbmap -print" give the same output before and after the switch?

no - see below

I always used 14.1 and yes it was working with CTRL+ALT_L+right_arrow (or +k) until the last fixes. You probably remember that I compile all the packages, so if you have an idea what is the root cause and need someone to test. Let me know. I am not knowledgable of the source. I could look into the patches and see what changed, but I remember you had many discussions and iterations.

thank you in advance

Hi Emanoil, clearly something is happening when you switch and switch back with the KVM switch. The question is whether this is: 1) a TDE issue woth R14.1.0 2) a TDE issue that was always there but that you never experienced with Ctrl+Alt_L+right arrow 3) a system issue

You can try reverting the commits in https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/304 and build the old version. Then do the same checks and see if you still get different key events before and after the switch. Also report the output of "setxkbmap -query" and "setxkbmap -print" before and after switching the keyboard. This should give you some idea of what to do next. Btw what key combination are you using now to switch? And how do you set it if that is not possible from kxkb?

Cheers Michele

Hi Emanoil,

It is definitely a result from the patches, because as said before, it was working all the time in 14.1. It stopped working or better the issue appeared after installing the last version with the patches

Not necessarily, because you are using a different key combination (due to the fact that the latest changes made impossible for you to set your previous combination) and therefore this opens up a lot of possibilities for errors. It is quite possible that the problem was always there and it didn't happen with the previous key combination and so you never noticed that. That is why I asked all those questions.

Michele, I reported them ("setxkbmap -query" and "setxkbmap -print") already in the previous posts.

I mean the output after reverting the changes. Again this is a test to see if the problem was already there or not.

To me it seems that for some reason the layout is being reset when disconnecting and connecting the keyboard (after the last patches).

Yes, it looks like that. So to collect more info, we need to compare the behavior with the same key combination (Alt_L+Shift_L) with and without the changes. Likewise it would be good to compare the behavor with CTRL_L+ALT_L+<right arrow> with and without the changes, if you can find a way to set that key combination from command line or using kbbswitch.

I may be proven wrong, but I suspect the problem was always there but simply you never ran into it due to the different key combination.

Cheers Michele

On 2023/05/19 01:01 AM, deloptes via tde-users wrote:

...

I may be proven wrong, but I suspect the problem was always there but simply you never ran into it due to the different key combination.

Hi, I now understand fully what you mean. But look, isn't it just possible to assign the old key combination? I remember you were discussing this seomwhere

Hi Emanoil, currently it is not possible in kxkb (we missed out on that :-( ) but we have plan to reintroduce that for R14.1.1. So you can either:

1) wait for the feature to be re-introduce 2) revert the changes in your local build and go with the old code 3) live with the KVM switch issue 4) further troubleshoot the current problem 5) try to use kbbswitch, which allows to use TDE shortcut to switch language, but it is missing a language toggle command

Of course the options are not fully exclusive :-)

Cheers Michele