OpenBox and keyboard/font/codepage bug

Please reproduce your error on a second machine before posting, and check the error by running without saved changes or extra modules (See FAQ No. 13, "How to report a bug"). For unstable Porteus versions (alpha, beta, rc) please use the relevant thread in our "Development" section.
Post Reply
michalpelszyk
White ninja
White ninja
Posts: 7
Joined: 16 Apr 2020, 17:42
Distribution: Porteus OpenBox

OpenBox and keyboard/font/codepage bug

Post#1 by michalpelszyk » 16 Apr 2020, 20:43

I love Porteus for the 2 older laptops I have lying around. It makes them boot dozens of times faster than any other desktop distribution (or Windows, for that matter) :Yahoo!: .
I also love the OpenBox version the most (for looks AND speed), but it seems to be the one I can't use due to bugs that make me unable to type in my own language.
I checked other builds ( by swapping the 003-.* base package) and all of them work just fine: XFCE, LXDE, LXQT, Mate, Cinnamon - only the OpenBox seems to have an issue.
For reference: picture of XFCE with a few letters typed that show as they should with the word "łóżko":
https://imgur.com/a/Abzn3yE

Can't do it on OpenBox: https://imgur.com/a/fbAyoEr

What's more, after I set the keyboard in the porteus.cfg file (/porteus/porteus-v5.0-x86_64.cfg to be precise), other DEs seem to pick it up but not OB: https://imgur.com/a/Xe4KxCw

To reproduce:
* Set the keyboard to Polish (via Porteus Settings Centre, setxkbmap or config file)
* Attempt to type letters with diacritics, e.g. RAlt+L

Porteus version: 5.0 x86_64

No other packages are required to make it work on other DEs - the characters are already there in default fonts.

PS. Version 4.0 of Porteus had the same problem. In addition on LXQT the console font could not do it either, but it seems to work in 5.0.

PS2. I was also not able to get the localisation in 4.0 working for OB (it doesn't work in 5.0 because it's not available yet, right?). It always get stuck on downloading the first file (glibc-i18n-x86_64-1jay.xzm). This even after USM is able to fully update the databases.
I have downloaded the files it tries to get and put in /porteus/modules, but then Porteus simply does not boot at all. Files: pl_PL-locales-files.xzm, pl-core_locales.xzm, pl-openbox_locales.xzm, glibc-i18n-x86_64-1jay.xzm

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2480
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

OpenBox and keyboard/font/codepage bug

Post#2 by ncmprhnsbl » 17 Apr 2020, 02:36

hi, welcome to porteus,
with the openbox keyboard layout, gxkb controls this, so try editing /home/guest/.config/gxkb/gxkb.cfg
line:

Code: Select all

layouts=us,ru,es
change to layouts=pl (or whatever combination you want, max of 3)
hopefully this works..
with localisation, is this failing only with openbox? does it work with the other DEs?
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

michalpelszyk
White ninja
White ninja
Posts: 7
Joined: 16 Apr 2020, 17:42
Distribution: Porteus OpenBox

OpenBox and keyboard/font/codepage bug

Post#3 by michalpelszyk » 17 Apr 2020, 09:00

Strange, I set the config via Porteus Config Centre, then via porteus(...).cfg, then via xorg.conf.d/(...).conf but didn't look into gxkb.cfg yet - and it was the default one. See https://imgur.com/a/MmZoqwP

However, changing this to PL did hot help at all - the issue is still the same.
New information from an experiment:
Set 2 layouts to PL (QWERTY) and FR (AZERTY), no variants.
When FR layout is active, I get "azerty" typing normally (as expected) and "æ«€¶ŧ" using the same keys with RAlt - this is as expected
When PL layout is active, I get "qwerty" typing normally as expected but get "azerty" when typing with RAlt. Why would using RAlt in PL layout cause it to type in FR instead of using properly assigned Polish diacritics?
The screenshot summarising this is here: https://imgur.com/a/zzvmyym

I checked a diffrent distribution using OpenBox (CrunchBang) and it was able to handle PL keyboard layout properly: https://imgur.com/a/kCpSdce

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2480
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

OpenBox and keyboard/font/codepage bug

Post#4 by ncmprhnsbl » 17 Apr 2020, 12:59

the problem seems to be with gxkb... here's what i did:
quit gxkb (rightclick on the flag and quit) and maybe rename(.bak) or delete or move ~/.conifg/gxkb/gxkb.conf
edit /etc/xdg/openbox/autostart > comment or remove entry: gxkb &
logout/login
then setkbmap pl works as expected ... πœę©ß←↓
but.. then i re-enabled gxkb and it didn't seem to be a problem.. like something got unstuck..
so .. unless you want the icon switching ability of gxkb, i'd say put your setxkbmap command in autostart and comment out gxkb..
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

michalpelszyk
White ninja
White ninja
Posts: 7
Joined: 16 Apr 2020, 17:42
Distribution: Porteus OpenBox

OpenBox and keyboard/font/codepage bug

Post#5 by michalpelszyk » 17 Apr 2020, 15:33

Thank you! :Yahoo!:
How the hell did you figure it out? :worthy:

The problem is triggered when "grp:switch" is present in "toggle_option" in gxkb.cfg, this is why removing the file allows gxkb to keep working fine - it is not present in the file generated by gxkb by default.

As far as I understand, "grp:switch" is RAlt and present in /usr/share/X11/xkb/rules/base.lst, and "grp:toggle" is listed there as RAlt well, so "grp:switch" is for temporarily changing language to the next one on the list for as long as it is pressed. This would explain why I was getting Cyrillic letters on default boots with RAlt..

This begs the question now: why would RAlt be set to swich layouts when it's used by so many layouts to type national script letters (PL and FR are not the only ones here). I can't be the first one to encounter this.

Also: can we get rid of this entry in future Porteus releases? So nobody else has to waste days on it like I did.

User avatar
Ed_P
Contributor
Contributor
Posts: 5510
Joined: 06 Feb 2013, 22:12
Distribution: 4.0 Cinnamon 64-bit ISO
Location: Western NY, USA

OpenBox and keyboard/font/codepage bug

Post#6 by Ed_P » 17 Apr 2020, 18:03

michalpelszyk wrote:
16 Apr 2020, 20:43
Porteus version: 5.0 x86_64
To be clear 5.0 hasn't been released yet. What you have/had was a year old release candidate (rc). 5.0rc1-x86_64
Ed

michalpelszyk
White ninja
White ninja
Posts: 7
Joined: 16 Apr 2020, 17:42
Distribution: Porteus OpenBox

OpenBox and keyboard/font/codepage bug

Post#7 by michalpelszyk » 17 Apr 2020, 18:49

Err... Yes, I should have made it clear that I understand it was rc1. It was present in final 4.0 too, though.

If you are saying it was already found and fixed in the current development release - that's great to hear!

Thank you very much again for looking into this, ncmprhnsbl.

User avatar
ncmprhnsbl
DEV Team
DEV Team
Posts: 2480
Joined: 20 Mar 2012, 03:42
Distribution: 5.0rc1-64bit all-DE+more
Location: australia
Contact:

OpenBox and keyboard/font/codepage bug

Post#8 by ncmprhnsbl » 17 Apr 2020, 23:51

michalpelszyk wrote:
17 Apr 2020, 15:33
How the hell did you figure it out?
well, i got a clue when setxkbmap worked properly in a setup without gxkb included..
didn't quite get as far as understanding the grp:switch part of it though, thanks for that :thumbsup: fixed in my build tree so it should good in the future..
the other thing that needs looking at is integrating this(gxkb) into the other porteus utilities/cheatcode for keymaps ... now on the todo list :)
Forum Rules : https://forum.porteus.org/viewtopic.php?f=35&t=44

Post Reply