9 May
2023
9 May
'23
3:16 p.m.
Hi folks,
after upgrading to R14.1.0 I miss the old way of switching between keyboard layouts with
Ctrl+Alt+K.
It looks like the option to NOT use xkbd is missing and the only option to toggle is now
xkbd.
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.
I prefer TDE because its basic functions have not fundamentally changed since the KDE3
era, and
after twenty years of using the shortcut Ctrl+Alt+K, I have a hard time getting used to
the "new"
shortcuts.
Is there any way to revert back to the original keyboard shortcut for switching the
keyboard layout?
Many thanks
Best regards
--
Petr Palacky
Outgoing message is virus free
because we are using Linux.
Debian GNU/Linux 12 (bookworm), kernel 6.1.0-2-amd64.
10 May
10 May
12:54 a.m.
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).
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
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.
Cheers
Michele
1:07 a.m.
Hi Peter
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.
Cheers
Michele
6:45 a.m.
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
7:27 a.m.
deloptes via tde-users wrote:
Interestingly after getting latest changes installed I
do not experience
any issues - CTRL+ALT+<Right Arrow> works as before
xkbd is disabled here
Correction
I now started the configuration dialog and suddenly (after closing the
window with OK) it stopped working. The key combination was empty, so I now
opened the configuration window and set the windows style Alt+Shift. Also
xkbd is enabled by default now.
BR
6:28 a.m.
Hi Michele,
thank you for your response
Elegant solution. Thanks a lot.
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 :-)
Hi Peter
It would be very nice step to revert back this functionality :-)
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).
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
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.
Cheers
Michele
6:52 a.m.
On 2023/05/10 03:28 PM, Petr Palacký wrote:
It would be very nice step to revert back this
functionality 😄
Issue already logged
https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/issues/342
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
9:51 a.m.
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
11:38 a.m.
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
1:01 p.m.
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
11 May
11 May
12:32 a.m.
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
5:55 a.m.
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
7:49 a.m.
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
9:25 a.m.
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
11:59 a.m.
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
12:57 p.m.
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…
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
12 May
12 May
7:58 a.m.
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 
9:22 a.m.
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):
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
--
Slávek
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
12:50 p.m.
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):
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/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
18 May
18 May
3:52 a.m.
Thanks Petr,
I have added your suggestion to the Wiki Tips and Trick page
https://wiki.trinitydesktop.org/Tips_And_Tricks#Troubleshooting
Cheers
Michele
On 2023/05/12 09:50 PM, Petr Palacký via tde-users wrote:
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
12 May
12 May
9:46 a.m.
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
15 Jun
15 Jun
4:29 a.m.
On 2023/05/10 03:28 PM, Petr Palacký via tde-users wrote:
It would be very nice step to revert back this functionality 😄
The ability to switch keyboard layouts using a standard TDE keyboard shortcut has been
re-added to R14.1.1-devel,
so you can now use either X11 or TDE shortcuts for the task.
We also added keyboard shortcuts to cycle through layouts in kkbswitch.
More info at:
https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/issues/342
https://mirror.git.trinitydesktop.org/gitea/TDE/kkbswitch/issues/6
Cheers
Michele
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).
12 May
12 May
9:06 a.m.
Michele Calgaro via tde-users wrote:
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.
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.
9:58 a.m.
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.
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".
Cheers
Michele
9:13 p.m.
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.
13 May
13 May
6:32 a.m.
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 Wmanoil,
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
6:33 a.m.
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
10:07 p.m.
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
17 May
17 May
10:48 a.m.
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?
BR
18 May
18 May
3:55 a.m.
On 2023/05/17 07:48 PM, deloptes via tde-users wrote:
Michele Calgaro via tde-users wrote:
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
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?
9:02 a.m.
Michele Calgaro via tde-users wrote:
Hi Emanoil,
do you get the same events (using xev) before and after the KVM switch?
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
Also, was it working fine with R14.0.13?
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
NOT WORKING after switching back
KeyRelease event, serial 40, synthetic NO, window 0x8600001,
root 0x11c, subw 0x0, time 1066034998, (382,427), root:(411,458),
state 0x19, keycode 64 (keysym 0xffe7, Meta_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 40, synthetic NO, window 0x8600001,
root 0x11c, subw 0x0, time 1066035062, (382,427), root:(411,458),
state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Working before switching to other PC
KeyPress event, serial 39, synthetic NO, window 0x8600001,
root 0x11c, subw 0x0, time 1066177346, (303,281), root:(332,312),
state 0x2010, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 39, synthetic NO, window 0x8600001,
root 0x11c, subw 0x0, time 1066177402, (303,281), root:(332,312),
state 0x2018, keycode 50 (keysym 0xfe08, ISO_Next_Group), same_screen
YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 39, synthetic NO, window 0x8600001,
root 0x11c, subw 0x0, time 1066177570, (303,281), root:(332,312),
state 0x4018, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 39, synthetic NO, window 0x8600001,
root 0x11c, subw 0x0, time 1066177650, (303,281), root:(332,312),
state 0x4010, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
NOT WORKING after switching back
$ 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)" };
};
WORKING before switching to other PC
$ 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)" };
};
1:33 p.m.
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
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
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
2:17 p.m.
Michele Calgaro via tde-users wrote:
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
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
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?
Michele, I reported them ("setxkbmap -query" and "setxkbmap -print")
already
in the previous posts.
As of how it was working. I configured the keyboard in TDE and changed the
key combination to CTRL_L+ALT_L+<right arrow>. This is what I was using in
the past 10y (at least). Now I switch with ALT_L+Shift_L.
To me it seems that for some reason the layout is being reset when
disconnecting and connecting the keyboard (after the last patches).
So after switching back I have to open the keyboard settings disable/enable
and press OK.
As mentioned before, I did not change anything anywhere related to keyboard
settings. I prefer using defaults as much as possible as it makes life
easier.
2:40 p.m.
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
4:01 p.m.
Michele Calgaro 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
11:55 p.m.
On 2023/05/19 01:01 AM, deloptes via tde-users wrote:
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
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
22 May
22 May
1:52 p.m.
Michele Calgaro via tde-users wrote:
On 2023/05/19 01:01 AM, deloptes via tde-users wrote:
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
Just for the record, it seems sufficient to run kxkb and all is good
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
319
days inactive
356
days old
38 comments
4 participants
participants (4)
-
deloptes -
Michele Calgaro -
Petr Palacký -
Slávek Banko