XFCE4 Keyboard Shortcut not working sometimes when logging in

Excuse me, I was having weird problem for several days now, I hold it, though that it would be fixed in the next update but I think it's time to ask if anyone else have had this problem.

I'm using XFCE4-gtk3 (manjaro default), everytime I turn on my laptop and login, sometimes (most of the times) my keyboard shortcut not working, and opacity configuration in the panel-out is resetted to 100.
When the problem does not happen, the opacity will be back to my last configuration, like 60 for example.

To fix it I have to log out and login again. It will fix the keyboard shortcut problem but not opacity.
Does anyone have experienced this? What is your solution?

Thank you.

EDIT:
What I mean by keyboard shortcut is this:
Oh it's called application shortcut..
SS_2019-01-28_00-11-44_067

System:
  Host: rapier Kernel: 4.19.16-1-MANJARO x86_64 bits: 64 compiler: gcc 
  v: 8.2.1 Desktop: Xfce 4.13.2git-UNKNOWN tk: Gtk 3.24.3 info: xfce4-panel 
  wm: xfwm4 dm: LightDM 1.28.0 Distro: Manjaro Linux 
Machine:
  Type: Laptop System: ASUSTeK product: X456UQ v: 1.0 serial: <filter> 
  Mobo: ASUSTeK model: X456UQ v: 1.0 serial: <filter> 
  UEFI: American Megatrends v: X456UQ.202 date: 02/15/2016 
Battery:
  ID-1: BAT0 charge: 19.2 Wh condition: 20.1/38.0 Wh (53%) volts: 7.6/7.6 
  model: ASUSTeK ASUS Battery type: Li-ion serial: <filter> 
  status: Not charging cycles: 133 
CPU:
  Topology: Dual Core model: Intel Core i5-6200U bits: 64 type: MT MCP 
  arch: Skylake rev: 3 L2 cache: 3072 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19204 
  Speed: 431 MHz min/max: 400/2800 MHz Core speeds (MHz): 1: 426 2: 414 
  3: 427 4: 411 
Graphics:
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: ASUSTeK driver: i915 
  v: kernel bus ID: 00:02.0 chip ID: 8086:1916 
  Device-2: NVIDIA GM108M [GeForce 940MX] driver: N/A bus ID: 01:00.0 
  chip ID: 10de:134d 
  Display: x11 server: X.Org 1.20.3 driver: intel 
  resolution: 1920x1080~60Hz, 1366x768~60Hz 
  OpenGL: renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2) 
  v: 4.5 Mesa 18.3.2 compat-v: 3.0 direct render: Yes 
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: ASUSTeK 
  driver: snd_hda_intel v: kernel bus ID: 00:1f.3 chip ID: 8086:9d70 
  Sound Server: ALSA v: k4.19.16-1-MANJARO 
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet 
  vendor: ASUSTeK driver: r8168 v: 8.045.08-NAPI port: d000 bus ID: 02:00.0 
  chip ID: 10ec:8168 
  IF: enp2s0 state: down mac: <filter> 
  Device-2: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter 
  vendor: AzureWave driver: ath9k v: kernel port: d000 bus ID: 03:00.0 
  chip ID: 168c:0036 
  IF: wlp3s0 state: up mac: <filter> 
  IF-ID-1: enp0s20f0u1 state: unknown speed: N/A duplex: N/A mac: <filter> 
Drives:
  Local Storage: total: 931.51 GiB used: 439.54 GiB (47.2%) 
  ID-1: /dev/sda vendor: Seagate model: ST1000LM024 HN-M101MBB 
  size: 931.51 GiB speed: 6.0 Gb/s rotation: 5400 rpm serial: <filter> 
  rev: 0001 scheme: GPT 
Partition:
  ID-1: / size: 58.05 GiB used: 17.81 GiB (30.7%) fs: ext4 dev: /dev/sda8 
  ID-2: /home size: 491.15 GiB used: 421.67 GiB (85.9%) fs: ext4 
  dev: /dev/sda5 
  ID-3: swap-1 size: 2.79 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sda7 
Sensors:
  System Temperatures: cpu: 46.0 C mobo: N/A 
  Fan Speeds (RPM): cpu: 0 
Info:
  Processes: 217 Uptime: 18m Memory: 7.69 GiB used: 2.74 GiB (35.6%) 
  Init: systemd v: 239 Compilers: gcc: 8.2.1 clang: 7.0.1 Shell: zsh 
  v: 5.6.2 running in: xfce4-terminal inxi: 3.0.30 

That's interesting. Not that I'm intending to use Manjaro for that much longer... but I have the same/similar problem. I noticed the first time when I just run the application launcher via or at least try to. Right after login it doesn't work... so I press the combination several times without effect. But some time later (don't know.. 10-20s) all at a sudden they are executed as if they had been queued and stuck somewhere.
Have a look if waiting a few seconds "solves" the problem. Just for curiosity I would be interested to learn about the cause and solution. I never had such a behavior with debian+xfce.

1 Like

Look for errors in the journal and ~/.xsession-errors

journalctl -b -p3
cat ~/.xsession-errors
cat ~/.xsession-errors.old

If you customize default shortcuts, a relevant file is created at

 ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml 

Also, you should compare Keyboard/Application shortcuts to WM/xfwm4 shortcuts, as they have precedence over Kbd.
You may view them with this

xfconf-query -c xfce4-keyboard-shortcuts -l

Another thing could be a mix of xfce4 versions (gtk2-gtk3)
Check with

pacman -Qs xfce4

or in Pamac GUI.

1 Like

It's a known issue, it isn't reported in bugzilla though, the problem relies in xfsettingsd not starting correctly at the first log in, to fix it you can make the command auto start or make a keyboard shortcut, or the way i do it, a launcher in the panel with no icon so only you know it's there
the command is
xfsettingsd --replace

2 Likes

As i mentioned before, it's a problem of xfsettingsd, it only happens in the gtk3 version AFAIK, your keys magically work after 10 or so seconds because manjaro uses a script as workaround for "fixing" this problem, you can check the script at /etc/skel/.config/autostart/xfce-pbw.sh and the commands it executes and content are

#/bin/sh
sleep 5
xfsettingsd --replace &
sleep 15
xfsettingsd --replace &
sleep 25
xfsettingsd --replace &

So it restarts xfsettingsd after 5 secs, then 15 secs, and then 25 secs to make sure everythings works fine. Though i don't know if you queues for commands are actually related to this.

2 Likes

no no, it's not delayed. It just completely not working.

Oh it works, thank you.

I think I'll switch to gtk2 then. Since I never had weird problem in gtk2 version when I was in other distribution.

Thanks everyone.

EDIT: hmm, getting a bit of hard time switching to gtk2, I'm not sure how to do it properly.

pacman -S xfce4 xfce4-whiskermenu-plugin xfce4-notifyd           [1]
:: There are 17 members in group xfce4:
:: Repository extra
   1) exo  2) garcon  3) gtk-xfce-engine  4) thunar  5) thunar-volman
   6) tumbler  7) xfce4-appfinder  8) xfce4-panel  9) xfce4-power-manager
   10) xfce4-session  11) xfce4-settings  12) xfce4-terminal  13) xfconf
   14) xfdesktop  15) xfwm4  16) xfwm4-themes
:: Repository community
   17) xfce4-panel-compiz

Enter a selection (default=all): 
warning: thunar-volman-0.9.1-1 is up to date -- reinstalling
warning: tumbler-0.2.3-2 is up to date -- reinstalling
warning: xfce4-terminal-0.8.7.4-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
warning: removing 'xfce4-panel' from target list because it conflicts with 'xfce4-panel-compiz'
:: xfce4-panel-compiz and xfce4-panel-gtk3 are in conflict (xfce4-panel). Remove xfce4-panel-gtk3? [y/N] y
:: exo and exo-gtk3 are in conflict. Remove exo-gtk3? [y/N] y
:: garcon and garcon-gtk3 are in conflict. Remove garcon-gtk3? [y/N] y
:: thunar and thunar-gtk3 are in conflict. Remove thunar-gtk3? [y/N] y
:: xfce4-appfinder and xfce4-appfinder-gtk3 are in conflict. Remove xfce4-appfinder-gtk3? [y/N] y
:: xfce4-notifyd and xfce4-notifyd-gtk3 are in conflict. Remove xfce4-notifyd-gtk3? [y/N] y
:: xfce4-power-manager and xfce4-power-manager-gtk3 are in conflict. Remove xfce4-power-manager-gtk3? [y/N] y
:: xfce4-session and xfce4-session-gtk3 are in conflict. Remove xfce4-session-gtk3? [y/N] y
:: xfce4-settings and xfce4-settings-gtk3 are in conflict. Remove xfce4-settings-gtk3? [y/N] y
:: xfce4-whiskermenu-plugin and xfce4-whiskermenu-plugin-gtk3 are in conflict. Remove xfce4-whiskermenu-plugin-gtk3? [y/N] y
:: xfconf and xfconf-gtk3 are in conflict. Remove xfconf-gtk3? [y/N] y
:: xfdesktop and xfdesktop-gtk3 are in conflict. Remove xfdesktop-gtk3? [y/N] y
:: xfwm4 and xfwm4-gtk3 are in conflict. Remove xfwm4-gtk3? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: removing xfconf-gtk3 breaks dependency 'xfconf-gtk3' required by libxfce4ui-gtk3

Try watching your keyboard lights at start.

I have had an issue where the loading of USB connected peripherals like mouse and keyboard was not done at the beginning but later in the boot sequence.

It was present at bios level preflight but dissappeared and when lightdm had finished loading it took 5-10 seconds for the keyboard and mouse to be active - sometimes longer.

So I think this is a systemd issue - which will be fixed when the updates reaches stable channel, but it could as well be xfsetting daemon.

I am using Openbox with xfsettings-gtk3 so I have a line in autostart loading the daemon on login.

The light is off except if I turned on the numlock but it works properly as I can use the keyboard to type both in lightdm and after login itself.

I think you can do it by running
# pacman -S xfce4 xfce4-goodies

an Update. I just switch to gtk2 xfce but the application shortcut problem is still there.
It actually introduce other problem with the theme.

I'm switching back to gtk3 and will just use workaround

2 Likes

What a baaad hack! I found the file you mentioned ..
I just created a script calling it once to test the behavior. And I confirm that after execution of the script right after login the key shortcuts work immediately.

This is a very ugly workaround, considering this is not reported upstream.
The least that could be done is a proper report at xfce bugs.
:disappointed::sneezing_face::man_facepalming:

I was thinking of doing that, but if this only happens on manjaro, then it's something in manjaro that causes that behavior, so until i know it happens in other distros, i can't really report it, and we still don't have a way of reproducing it, what would it be?, install manjaro, wait for weird things to happen?.

It's not that baaaad, it just doesn't work for everyone and upstream doesn't know everything. I haven't had that problem happen since manjaro 18.0 so i can't really test it, i was thinking of installing all git components of xfce one by one to know which was the cause or if it's reproducible.

Then how come

Who created a permanent solution in Manjaro and why, without an upstream report? Manjaro devs are inline to reporting this type of issues upstream before/while creating a temporary fix.

Something feels off here.

oh no! @AgentS knows the truth!, the conspiracy has been unveiled, we should silence him before he tells someone else and asks @philm about this :sunglasses: .

It doesn't work for everyone because the problem that the script tries to solve also deals with autostart, so if autostart doesn't work because xfsettingsd doesn't start correctly the script that tries to fix the issue won't be launched and as such your autostart won't work and keyboard shortcuts and themes and icons and yadayadayada and basically you won't have a solution.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by