Debian 11 can't write underscore symbol "_"

[Askarus]

Maybe a file is the wrong name or permissions? I seem to recall .xmodmaprc.

But these mappings would apply to terminal mode too right? Not just when running x11. There might be a better, more low level way of doing the mapping.

If your getting annoyed I'd put it in you .bashrc and call it a day.

I put it into the .bashrc. .xmodmaprc also did nothing.

 

[Askarus]

So here's an update. I am investigating this issue and checked how funkeymonkey works.
If you are interested in the matter check the first answer here: Link
It's quite long, but very easy to understand, so I encourage everyone to read it.

So what we do is something like this
kernel -> funkeymonkey -> xkb

What we do not need is the .Xmodmap file. It has no effect or gets overwritten by something. So we can delete that layer.
The other layers are intended and in my opinion should not be merged (See that Reddit topic).

The issue we have with the Pyra is that we have more letters than what is on a regular keyboard. So we need to misuse some KEYCODES that are non letters but for example media keys.
Here for example
[COLOR=rgb(0, 0, 0)][SIZE=16px][FONT=gg sans][LIST=1] [*][SIZE=16px][FONT=inherit][SIZE=16px][FONT=inherit][SIZE=16px][FONT=inherit][COLOR=var(--text-normal)][FONT=inherit][SIZE=16px][FONT=inherit]global.behaviors->altmap(KEY_D, &global.Fn.pressed, KEY_D, KEY_SOUND); // I221 // ok[/FONT][/SIZE][/FONT][/COLOR][/FONT][/SIZE][/FONT][/SIZE][/FONT][/SIZE] [/LIST][/FONT][/SIZE][/COLOR]
That is because funkeymonkey does provide real KEYCODES for the fn keys and does not require X11 to do the layer switching.
(That is what the old Xmodmap was designed for but is now without any effect).

So to fix the missing _ and : I need to find the old xkb file and update it.
I suppose that some KEYCODES have changed between Debian releases or Kernel updates or whatever.

(That is a summary about what I flooded the IRC with today. Maybe someone is interested in that)

 

[Askarus]

Seems I can't post links. github dot com rvaiya/keyd could be an interesting solution for mapping the keyboard if it supports french/german symbols properly. It's a low level daemon so we could potentially cut out all the X stuff and get some nifty benefits, like retaining the mapping over a moonlight session.

I have checked that. Is you see the above description, this might not be useful to us. I would have loved to use it.
However the issue is that in the chain kernel -> funkeymonkey -> xkb this would replace the xkb part but not the funkeymonkey part.
We need funkeymonkey for more advanced tasks like switching between gamepad and keyboard for the D-Pand and ABXY.
Also I have no idea how well bot h daemons would work together.
Further keyd was made witth letters and a standard keyboard mapping in mind from what I see. I am not sure if it would remap for example the pause-key to a letter.

So even if something that is X11/Wayland agnostic sounds appealing, I think doing the mapping in xkb is the better option.
Most things should work even without some special mapping anyways. It's mainly the extra characters like äöü that require remapping of those special keycodes.

I do not know why _ and : are broken, but now I at least know where to search and that .Xmodmap is not the place for it.

 

[Askarus]

Okay, so some more progress. If I do
setxkbmap -symbols pyra
then _ and : do work.
However the Pyra key has issues. Mate recognizes it as 0xffffff.
I can still use the Pyra key to trigger MATE shortcuts but Tilda (overlay terminal) does not recognize it any more.
For me CTRL+Pyra is important to open a terminal since it is a nice to reach button combination.

Also for some reason is I do
setxkbmap -print
before and after manually loading the pyra with the command above, it outputs the exact same.
So it seems like the settings get loaded but something causes issues for _ and :
And no idea why manual loading breaks the Pyra partially.

Currently the Pyra key is mapped to MenuKB. I would suggest to map it to SUPER_L. No idea why MenuKB was chosen. SUPER_L has much better compatibility out of the box for start menus and can be used for both, as a stand alone trigger and as a modifier.

EDIT:

I spent hours checking this and experimenting. Underscore reads just fine after manual reloading.
If I replace any of the other key codes with underscore that works just fine.
So the next step will be to modify funkeymonkey and replace the key code for _
Currently it is I222 - KEY_SOUND.
Maybe that causes some issues at boot time. Why should that not work and others do?

I hope I can get this set up in the evening. It's just a quick edit but I need to set up the Pyra for compiling and testing first.

 

[Linux-SWAT]

Could be that you have to delay a bit this command, because it's overwritten when the desktop manager starts.

 

[Askarus]

Heads up everyone. aTc patiently helped me to get the build process set up.
So I can play around with funkeymonkey tomorrow.
Let's hope that simply changing the key code of : and _ will fix the issue.

Post automatically merged: Feb 19, 2024

Could be that you have to delay a bit this command, because it's overwritten when the desktop manager starts.

Might be.
I will test that next if changing the key code does not help.
However if I delay the command I have the suspicion that the Pyra key and the right upper shoulder button (ALT) will be broken.
That is because manually reading the pyra xkb config breaks those.

In any case it is good that I understand the whole input chain now. At least we know now that we can remove the confusing Xmodmap.

Also now that I know how the pyra relevant part of funkeymonkey works I will work on that to make it a lot more user configurable and to make it read everything from a config file.
I also want to add FN key codes to the arrow keys an the game pad keys (if I find enough that are working)
So we can use those for brightness volume or whatever. I see no reason to waste those buttons.

Also we should discuss the Pyra key's mapping. It is currently mapped to MenuKB. In my opinion SUPER_L (Windows key) would make a lot more sense.
That whole topic is nothing we should discuss here. It's just some ideas I have.
I'll open a new thread for this when I will have a look.
(I can fee Sebt3 and aTc objecting. Not that they could stop me ...)

 

[Askarus]

I finally modified Pyrainut so that it dynamically overwrites its default key mapping when the key is set in its config file.
Now I need to verify my theory and see if the issue here can be fixed if I find a key code that is not being used by anything else.
That should be less pain now since all I need to do is to update the fine and restart the service.

Even if that does not fix the problem, giving users the option to freely remap key codes will surely be useful.

 

[jedi23]

I appreciate your efforts and it would be great to have a hassle free solution for this issue.
I posted it already elsewhere but in case someone doesn't know yet: Fn + Shift (L1) + ";" or "-" gives you the according ":" and "_" characters.
I think this is the best workaround until this issue is fixed!

 

[Askarus]

I appreciate your efforts and it would be great to have a hassle free solution for this issue.
I posted it already elsewhere but in case someone doesn't know yet: Fn + Shift (L1) + ";" or "-" gives you the according ":" and "_" characters.
I think this is the best workaround until this issue is fixed!

This is what I use.

I fear that for the time being this will be what we have to use to type those letters in the terminal.

 

[netcat]

And the anolog sticks control the mouse pointer right? Just checking.

 

[Askarus]

And the anolog sticks control the mouse pointer right? Just checking.

Yes. Either that or the gamepad. You can switch this via config.

I was again looking for a way to make the key mapping not reliant on xkb and the limited amount of key codes it has access to. However I did not find anything that could work properly.
So I guess I will continue with the original plan to try all the non-letter codes that are not being used by us and hope to find 2 that we can use.

 

[Askarus]

Okay, I finally had some time to investigate this further.
The reason why _ and : do work if we do
setxbkmap -symbols pyra
is because the rule we currently apply at boot goes like this
pc+pyra(pyra)+evdev(inet)

So when booting the special symbols we define in our pyra file got overwritten by inet.
If we manually load the pyra symbols, those overwrite the inet rules.

Now I checked the inet symbols and there some of the lines were commented out.
Those are the ones we use in the pyra layout.
It seems that not all the xkb definitions we use were properly commented out in the inet symbol definition and thus they now overwrite the Pyra symbols.
If I manually define _ in the inet symbol definition, then those changes get active after boot.
So that for me is an indication that my hypothesis from above is correct.

We now have 2 options
1. Modify the inet symbol definition and properly comment out whet we use
2. Make it so that the pyra layout loads after evdev(inet) and gets priority.

The former would be easier, however I prefer option 2.
That is because this solution would not touch the inet symbol definition and out pyra layout will always take precedence.

 

[Git1]

Okay, I finally had some time to investigate this further.
The reason why _ and : do work if we do
setxbkmap -symbols pyra
is because the rule we currently apply at boot goes like this
pc+pyra(pyra)+evdev(inet)

So when booting the special symbols we define in our pyra file got overwritten by inet.
If we manually load the pyra symbols, those overwrite the inet rules.

Now I checked the inet symbols and there some of the lines were commented out.
Those are the ones we use in the pyra layout.
It seems that not all the xkb definitions we use were properly commented out in the inet symbol definition and thus they now overwrite the Pyra symbols.
If I manually define _ in the inet symbol definition, then those changes get active after boot.
So that for me is an indication that my hypothesis from above is correct.

We now have 2 options
1. Modify the inet symbol definition and properly comment out whet we use
2. Make it so that the pyra layout loads after evdev(inet) and gets priority.

The former would be easier, however I prefer option 2.
That is because this solution would not touch the inet symbol definition and out pyra layout will always take precedence.

Awesome work! Congratulations on finding the solution to this. It'll be a long time before I get a Pyra, but it is great to see work going on to improve it. Makes the project feel more alive.