Tablet PC: Pen-Monitor & Remote Mapping, WINE Pen Pressure & More <partially solved>

[Sasha-Jen]

But what other files do you have in that folder?

10-amdgpu.conf
10-nvidia.conf
10-quirks.config
10-radeon.conf
40-libinput.conf
70-wacom.conf

I looked into libinput since, well, it had "input" in it and it has sections on tablet, touchscreen, touchpad etc

Section "InputClass"
Identifier "libinput tablet catchall"
MatchIsTablet "on"
MatchDevicePath "/dev/input/event*"
Driver "libinput"
EndSection

I looked into /dev/input/event*, are the numbers of all events the device IDs? It comes up with "no application installed for character device files" and I'm not going to force any to open even in the text editor due to uncertainty. Do you think my tablet is using this libinput driver? Or did you have something else in mind and I'm going in a way off direction on why you brought this up.

 

[wizardfromoz]

No Sasha, that's fine, I'll explain.

My first significant experience with the contents of that folder came with troubleshooting the reverse of the type of functionality you seek, that is, with permanently disabling a device.

My old Toshiba Satellite laptop has a touchscreen, which had been acting up since the get go, even on Windows 8 before I blew that away and installed all Linux. Turned out the laptop was refurbished, which I was not aware of when I bought it.

The mouse cursor would jump all over the screen (without even touching the mouse) vibrate up and down, even click and move icons drag and drop style. This could occur from as early as the login screen.

With xinput, I was able to identify the device as 10, and then

xinput disable 10

would disable the touchscreen (but resume normal mouse cursor) but only for the session.

I then found files such as 40-libinput.conf (which you have) and 10-evdev.conf. For distributions where only one file occurred, I just had to comment out the lines related to touchscreen and save the file and then reboot.

For Distros where both files occurred I had to do it with both to get it to take. Problem solved, for me.

Hence my asking what you had in .../xorg.conf.d/ in case there was a way there to make your changes permanent, by adding to those files.

You can issue a command

cat /proc/bus/input/devices

which will show all your devices, and you can see by comparing that with the output of xinput that they do not match, so

...are the numbers of all events the device IDs?

No.

I performed a Google search under

linux /dev/input/event files

which may have some helpful material, including the one I got that command from

https://thehackerdiary.wordpress.com/2017/04/21/exploring-devinput-1/

... but that is about as far as I can go, sorry I can't be of further help for now, but if I spot anything useful, I will be back.

Cheers

Wizard

 

[Sasha-Jen]

Thanks @wizardfromoz that's a lot of info I've been playing around with for the past few hours.

I haven't tried adding to the config files yet (simply was too busy exploring the other parts of your post) but I certainly will try it.

As to the device commands, I feel I am finding different ways to get physical information about them ("oh, this device is located in the 2nd port of the 3rd hub" or whatever) but not much of the virtual side of it. As in, the driver/settings. Yes, the whole events thing is interested but after reading that link I'm not sure how it helps me change the shortcut remote mapping. I've also tried simply searching for "how to know what driver a device is using" and the results are more to do with non-usb devices e.g. ethernet driver, the driver for the usb hub itself but not the devices plugged into it.

I also attempted to find a lead on getting pen pressure to work in medibang with no avail. You see, there is a secondary, more minor but just as annoying problem with it: the initial start pop-ups plus the drop-down menus are open in the top-left of the wrong monitor (my right monitor all the time). Results were all windows while I know it is a medibang through WINE issue. I just kinda thought if I found the solution to the more minor medibang issue it could lead me to solving the pen pressure issue.

I'll take a look again at all this new info. Seems a lot of times it takes me a 2nd session to really understand new things. Although the more complex I go the harder it is to find the correct solution. There's been a lot of red herrings that either fail to work or initially look promising but were not relevant.

Hard to believe all this has really stemmed from 2 non-repository programs: medibang (which ofc I use the tablet & shortcut remote with) and REAPER DAW, and we've solved the latter fairly quickly. So the vast majority of this whole thread has been about getting medibang to a working order. Going into complex device info commands and stuff. All to change the settings of devices that are working, just mapped in ways that have no use.

Anyway, I'm sure I'll do another linux problem-fixing session later today (it is 8AM rn). Speaking of "what this thread has turned into". I was thinking of changing the tags and title to something more reflective of it. Someone who has a working non-XP-Pen tablet that just needs mapping to the proper screen might read the title and think "that isn't my tablet so skip reading" despite the solution to their problem being here. So, is there any ideas for a title that encompasses:

• Audio input/output
• tablet pen remapping (non-brand specific)
  
• shortcut remote key remapping (hopefully a non-brand specific solution will be found)
• pen pressure for art programs through WINE (I think it is looking like a medibang through WINE issue specifically though).

 

[wizardfromoz]

I was about to sign off on my evening in Oz, here, but chanced to see your Post

That is considerate of you to think of others, and I quite agree.

Maybe something like "Tablet PC - Audio, Pen, Remapping & Other Issues Explored and Found (or not)"

Clunky, perhaps, but having Tablet up front is always good value.

Gotta fly

Avagudweegend

Wizard

 

[Sasha-Jen]

I've attempted to follow this key remapping tutorial: https://unix.stackexchange.com/questions/156985/keyboard-hard-remap-keys which requires to explore the links within it.

The same issue has occurred with the key remapping: the keys on different keyboards (actual and remote) are recognised as the same keys. Through going into the virtual console (first time, spooky!) and using showkeys, I got the same output for actual "p" and the middle-bottom remote key that outputs "p": x19 when pressed and x99 when released. Which seems a different format than what the tutorial says with

"7e" (keypad ".")

This is most frustrating as in the tutorial there is a portion that shows

KEYBOARD_KEY_7e=36

Which is the exact format I am looking for: [physical key] <remapped to> [virtual output (keycode)].

At this point it is pretty clear that the remote keys are not recognised as their own keys. The only issue with this is that it does not make any sense at all. I've already said this, but how can 2 physically seperate devices be accurately recognised as 2 separate devices yet the keys on each device are thought as the same physical keys? Shouldn't this mean there is no way to remap them? Yet how does it happen in windows? I don't believe it is a Linux issue here. Unless I am majorly misunderstanding something, I don't think XP-Pen coming out with a linux driver for their shortcut remote that can solve the physical keys not being recognised as separate as an actual keyboard.

If there is a problem and there isn't a piece of software with a command that should solve it, then "oh well there isn't currently a way to solve it" but this comes across as just wrong. I've attempted several pieces of console software that are made for remapping physical keys yet the 2 devices always share the same physical key identities. No matter what hitting the default "p" on both of them give the same output. This is contradictory to the whole fact that they are separate physical keys on separate physical devices.

I'm sure if I bound "space" to space and "e" to space they will retain their same physical identity separate from each other despite the same virtual output, yet 2 devices share the same physical keys... apparently. As every piece of software to do with key remapping is telling me.

FYI I also tried evtest too and no different. This is legit frustrating now.

 

[wizardfromoz]

This is legit frustrating now.

I can't even begin to imagine, although I can sympathise.

Mate, I'll throw a curve ball here, which may or may not help, depending on whether having LM 19.1 MATE is a dealbreaker or not.

At Manjaro, this

https://forum.manjaro.org/t/have-i-got-xp-pen-artist-15-6-pro-install-preparation-right/75917

I've read it from top to bottom, but will likely make more sense to you.

I have Forum memberships at a couple of other places, where I might only make an appearance once or twice a year (because I am here 99.9% of the time). Manjaro is one of them, and I have found them to be good people.

The unit referred to is a 15.6 Pro, and so differs somewhat, but it indicates that there is activity there in this field, and it is current . It also mentions mapping.

MJRO have a currency of 30 days on their Threads' activity before they are closed, and this one is up to 24 days, so you may wish to join and stick your 2 cents into that Thread, or else start your own.

Of course, if you find an answer there or elsewhere, we hope you will share it with us, so we can grow our Wiki (it needs it, in Tablets, lol).

Of the 80 or so LInux I run, apart from the usual sprinkling of LM and Ubuntu, I run a sizeable bunch of Arch-based, including Manjaro (Xfce, MATE, Cinnamon, &c), so could certainly assist in that regard, should you choose to change Distros.

Also FYI, it is strongly alleged that GNOME is the best DE (Desktop Environment) supporting touch technology (but I have no personal evidence of that either way), and Manjaro have a GNOME.

Just throwing it out there to you.

Cheers

Chris

 

[Sasha-Jen]

I read it, but unfortunately I decided on Mint months ago near when this journey all started with that atrocious Windows 10 update that was wiping peoples' storage devices whole. There were small and other large issues I had with it, but that was the breaking point. I did look into distros like Manjaro and SUSE and such, but it all came back to Mint.

I think if I could identify what driver is being used for the remote I may be able to progress from there. Maybe not though. Then it's just the WINE pen pressure left.

I may start setting up a virtual WIN 10 and settle with that until new info comes to me that can settle it. FeelsBadMan to go through all this learning and exploration and reach a brick wall here.

 

[Sasha-Jen]

Added a thread summary at the top of first post to go with the tags and title update to help with future people searching for same/similar problems.

 

[Sasha-Jen]

https://bugs.winehq.org/show_bug.cgi?id=40199

Medibang pen pressure through WINE has not worked, probably since forever, but first reported early 2016. The last reply doesn't really make sense though:

This bug needs logs to start working. The default wine output is just fine when you are trying to use the program. If some special channel needs to be used they will tell you.

The most I can understand from that is some type of log output needs uploaded before fixing can start. I found a page that I then instantly lost and couldn't find it again (I know, figures) but in it said this command:

wine <yourprogram>.exe &> /tmp/log.txt 2>&1

"yourprogram" I put back in becuase I can't remember its exact wording, but ofc you are suppose to replace it with your actual program name. So I did and got this:

wine: cannot find L"C:\\windows\\system32\\MediBangPaintPro.exe"

The latter part of the command is to output the result into a log file. The output is right that medibang is not installed in that directory (or even no .exe file in that one). The location is /drive_c/Program Files (x86)/Medibang/MediBang Paint Pro/MediBangPaintPro.exe yet I've failed to redirect it to there in the terminal.

If I can get this log file I think I can upload it to the bug report and then they may start working on fixing it?

 

[wizardfromoz]

Sounds like a plan

Wiz

 

[Sasha-Jen]

I've done a bit more reframing. If I cannot change the output of individual keys on a second device, then I will change the output of the keys from a secondary device. Ergo:

['p' from device2] = [space]

I found this tutorial: https://superuser.com/questions/760602/how-to-remap-keys-under-linux-for-a-specific-keyboard-only

From it, I have the keycodes that the 9 keys on my shortcut remote correspond to, and then the codes for what they will be changed to. My notes currently look like this:

Key Keycode Change to

1= 55 <AB04> <AB05>
2= 31 <AD08> <DOWN>
3= 65 <SPCE> <AD03>
4= 56 <AB05> <LCTL> + <AB01>
5= 36 <RTRN> <UP>
6= 52 <AB01> <LCTL> + <AD06>
7= 58 <AB07> <LCTL>
8= 33 <AD10> <SPCE>
9= 30 <AD07> <LALT>


↳ Polostar 2.4GRF Keyboard id=19 [slave keyboard (3)

There is a problem though, and I have re-read it numerous times. When the tutorial comes to this part:

remote_id=$(
xinput list |
sed -n 's/.*GASIA.*id=\([0-9]*\).*keyboard.*/\1/p'
)
[ "$remote_id" ] || exit

# remap the following keys, only for my custom vintage atari joystick connected
# through an old USB keyboard:
#
# keypad 5 -> keypad 6
# . -> keypad 2
# [ -> keypad 8
# left shift -> left control

mkdir -p /tmp/xkb/symbols
cat >/tmp/xkb/symbols/custom <<\EOF
xkb_symbols "remote" {
key <KP5> { [ KP_Right, KP_6, U2192, U21D2 ] };
key <I129> { [ KP_Down, KP_2, U2193, U21D3 ] };
key <AD12> { [ KP_Up, KP_8, U2191, U21D1 ] };
key <LFSH> { [ Control_L ] };
};
EOF

setxkbmap -device $remote_id -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i $remote_id -synch - $DISPLAY 2>/dev/null

I don't know what this is. It's clearly is what you put into a file, and you change parts to correspond with your own device and remapping needs. The problem is I don't know what file this is nor where to create it nor what exact parts I need to change.

There was a previous tutorial (it didn't work for me, but not the point) that literally went through each step. As in in included <create a file in this direction and call it this>, <put this in it as a default config> <change these parts to suit your own needs>. It was great and easy to understand. This tutorial at this point, the most i can get is:

Then source it (you can add it to your .xinitrc).

Ok, I guess "source it" means put it in the correct file etc, but I don't have a file named ".xinitrc" on my system and there's no indication where to create such a file, and again, I don't know what exactly to change from the example given.

Am I literally skipping over a sentence or something in this tutorial? I feel like I am because it seems a step has been skipped that links getting the keycodes with that text that is the actual remapping itself.

 

[Condobloke]

just a shot in the dark....

Using xinit without an .xinitrc
If you broke your ".xinitrc", or do not have one yet, then you can start one. For example:

these will work
$ xinit /usr/X11R6/bin/xterm
$ xinit $(which xterm)
this will NOT work
$ xinit xterm

This will start an X server and the program called "xterm", which you can use to start more X clients. The last line fails (even if "xterm" is in your PATH) because xinit assumes that it is an argument, not a program. You must have a slash / somewhere in the name of the program.

FROM...:: https://en.wikibooks.org/wiki/Guide_to_X11/Starting_Sessions

 

[wizardfromoz]

There is another option.

Take a look in your File Manager for /etc/X11/xinit/xinitrc

Note that that last file has no dot before it. If it has content, you can likely add to it what instructions and comments you need.

A further alternative is from Terminal, to create .xinitrc using touch

touch ~/.xinitrc

... and use nano to add the content.

Cheers

Wiz

 

[Sasha-Jen]

Thanks guys! You're both right. I in fact do have that file. I went ahead and copy/pasted into it with terminal nano. There's still the question of what exactly needs customising which I am unsure about. I went ahead and did what I could. The file now looks like this:

#!/bin/sh
#
# /etc/X11/xinit/xinitrc
#
# global xinitrc file, used by all X sessions started by xinit (startx)
#
# invoke global X session script
#. /etc/X11/Xsession
#
remote_id=19(
xinput list |
sed -n 's/.*GASIA.*id=\([0-9]*\).*keyboard.*/\1/p'
)
#[ "$remote_19" ] || exit
#
# remap the following keys, only for my custom vintage atari joystick connected
# through an old USB keyboard:
#
# keypad 5 -> keypad 6
# . -> keypad 2
# [ -> keypad 8
# left shift -> left control

mkdir -p /tmp/xkb/symbols
cat >/tmp/xkb/symbols/custom <<\EOF
xkb_symbols "remote" {
key <AB04> { [ AB05 ] };
key <AD08> { [ DOWN ] };
key <SPCE> { [ AD03 ] };
key <AB05> { [ LCTL, AB01 ] };
key <RTRN> { [ UP ] };
key <AB01> { [ LCTL, AB01 ] };
key <AB07> { [ LCTL ] };
key <AD10> { [ SPCE ] };
key <AD07> { [ LALT ] };
};
EOF

setxkbmap -device $remote_id -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i $remote_id -synch - $DISPLAY 2>/dev/null

I know that a line starting with # won't be processed, and I customised the remote (device) ID (some at least) plus the keys. I'm not sure if this is enough/if there are obsolete lines within it etc. I'm sure more of it needs to be customised, I just don't know what exactly. I mean, just customising what I have I don't think has worked. Unless I need to activate it somehow.

Ya see how much harder it is when a tutorial assumes you already know something? Oof. Actually, I'm not even sure if the keys that are suppose to be combinations are formatted right.

Edited addition:

As I've been stopped a few times by walls, during those times I've attempted to fix minor issues. The type of issues that aren't required to be fixed for my permanent adoption of Linux (unlike all the Medibang/tablet/shortcut stuff) but if I ignored them for 12 months they would start to feel annoying to have. I assumed they were so tiny that I would find solutions to them easily when I do get to them.

Seems not. There's three I've discovered so far, however the first is the mouse issues which I think will be able to be fixed the same way as the shortcut remote, I just need to try it. So no advice seeked for that one.

The two others are:

1. Program windows are expanding behind the panel. This isn't an issue most of the time, but for example, when I control+f in firefox, I can't see what I am typing. What if I make a typo? I pretty much have to type what I want to find a few times to make sure it really isn't on the page.

Attempts to search for a solution have brought up other panel-related problems (e.g. one was having a top & side panel and how they overlap) and nothing actually on program windows expanding behind the panel. Hiding the panel isn't a fix but a work-around, and one I don't want to do.

2. I have a TV as one of my monitors, and even in Windows 10 the image over-hanged the physical screen. I've attempted to change TV settings but none fix it. In Win 10 I fixed it by going to the nvidia control panel and "resizing" the screen.

This is not changing to a lower resolution. The problem is like having a 26 inch screen and the output was as if it was 28 inches: a bit of the screen is cut off at all sides; the solution I did in win 10 was to keep the resolution but change it as if it was a 25 inch monitor at full HD. A bit of unused space at all sides is better than the image going over and being cut off.​

 

[Sasha-Jen]

Edited the file again. It currently looks like this:

#!/bin/sh
#
# /etc/X11/xinit/xinitrc
# global xinitrc file, used by all X sessions started by xinit (startx)
#
# invoke global X session script
#. /etc/X11/Xsession
#
remote_id=19(
xinput list |
sed -n 's/.Polostar 2.4GRF Keyboard.*id=\([19]*\).*keyboard.*/\1/p'
)
#[ "$remote_19" ] || exit
#
# remap the following keys, only for my custom vintage atari joystick connected
# through an old USB keyboard:
#
# keypad 5 -> keypad 6
# . -> keypad 2
# [ -> keypad 8
# left shift -> left control

mkdir -p /tmp/xkb/symbols
cat >/tmp/xkb/symbols/custom <<\EOF
xkb_symbols "remote" {
key <AB04> { [ AB05 ] };
key <AD08> { [ DOWN ] };
key <SPCE> { [ AD03 ] };
key <AB05> { [ LCTL, AB01 ] };
key <RTRN> { [ UP ] };
key <AB01> { [ LCTL, AB01 ] };
key <AB07> { [ LCTL ] };
key <AD10> { [ SPCE ] };
key <AD07> { [ LALT ] };
};
EOF

setxkbmap -device $remote_19 -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i $remote_19 -synch - $DISPLAY 2>/dev/null

I sorta did skip over a sentence, but it didn't help much.

changing the sed line with one that fits your device's name.

Alright ok let's isolate and look at the sed line here:

sed -n 's/.*GASIA.*id=\([0-9]*\).*keyboard.*/\1/p'

Um okay. I can change the number of the id and I think it is clear enough that "GASIA" is where the name goes so I have:

sed -n 's/.Polostar 2.4GRF Keyboard.*id=\([19]*\).*keyboard.*/\1/p'

But, are all these other characters needed? Are they vital to keep, or are they meant to be dropped? Again, it isn't clear. I know "*" is a catch-all e.g. I could just right "Polostar*" for the name if I wanted to and it will still work; but what about the id? I'd assume it should just read "id=19" but it is not clear if those characters in the example are meant to be dropped or not. "*keyboard.*" seems fine as I think it identifies the device type that is given with "xinput list" but the seemingly random characters after that?

Then further down the example gives "$remote_id" numerous times. changing "id" to "19" is obvious, but is it meant to read "$remote_19" or "$device_19" or what? And is the "$" suppose to be there? Really, what is meant as an example to change and what is there as needed characters is really not clear. It's turning into a guessing game and I'd rather not guess with an executable like this.

So far what else I've read doesn't help any further than this e.g. the wiki that @Condobloke linked. Yes, I have not explored every single page (...yet...) so maybe the answers I seek are there and I just have to put in more time, but boy this has been an uphill struggle that's getting tiring.

 

[wizardfromoz]

Just regarding #34, there are some options available within xrandr to experiment with a custom resolution, and then other options to make those permanent, ie surviving a reboot.

Are you aware of them, or how to do so?

Wizard

 

[Sasha-Jen]

I decided to analyse the example script and break it down into manageable chunks. These chunks can also be used if anyone wishes to give advice by quoting the example chunk followed by the advice (and can also quote and compare my customisation). Note that I am not claiming I have it correct now. I have also numbered the lines for easier referral.

First portion:

1. remote_id=$(
2. xinput list |
3. sed -n 's/.*GASIA.*id=\([0-9]*\).*keyboard.*/\1/p'
4. )
5. [ "$remote_id" ] || exit

Line 1 seems simple enough that I have no comment. Line 3 is the next to change. I know to change the device name, however I am unsure if I need to change the device id. The reason being the *s around the id section I think indicate that any id is used, relying only on the device name and the type (the "keyboard" part, I think). I've gone and changed it to a hard id to make sure though. There is a comment on the linked tutorial that says to comment out line 5, I have deleted it. My customisation (numbered lines are not part of it and are added to this post after-the-face):

1. remote_id=19(
2. xinput list |
3. sed -n 's/.*Polostar.id=19.*keyboard.*/\1/p'
4. )

The next portion:

1. 1. # remap the following keys, only for my custom vintage atari joystick connected
   2. # through an old USB keyboard:
   3. #
   4. # keypad 5 -> keypad 6
   5. # . -> keypad 2
   6. # [ -> keypad 8
   7. # left shift -> left control

These are all comments that are not proceeded in the actual execution of the script. These lines describe what the change is in the example. They can be deleted or ignored; I've decided to edit them to describe what my script is changing. My customisation:

1. # To remap the nine shortcut remote keys

The next portion:

1. mkdir -p /tmp/xkb/symbols
2. cat >/tmp/xkb/symbols/custom <<\EOF
3. xkb_symbols "remote" {
4. key <KP5> { [ KP_Right, KP_6, U2192, U21D2 ] };
5. key <I129> { [ KP_Down, KP_2, U2193, U21D3 ] };
6. key <AD12> { [ KP_Up, KP_8, U2191, U21D1 ] };
7. key <LFSH> { [ Control_L ] };
8. };
9. EOF

Line one makes a directory while line 2 outputs contents into a new file within the new directory. I think the output is what is placed between the "EOF"s? Meaning all of lines 3-8. Those lines themselves are the key changes that are the whole reason I'm doing this. My customisation:

1. mkdir -p /tmp/xkb/symbols
2. cat >/tmp/xkb/symbols/custom <<\EOF
3. xkb_symbols "remote" {
4. key <AB04> { [ AB05 ] };
5. key <AD08> { [ DOWN ] };
6. key <SPCE> { [ AD03 ] };
7. key <AB05> { [ LCTL, AB01 ] };
8. key <RTRN> { [ UP ] };
9. key <AB01> { [ LCTL, AB01 ] };
10. key <AB07> { [ LCTL ] };
11. key <AD10> { [ SPCE ] };
12. key <AD07> { [ LALT ] };
13. };
14. EOF

One thing to note is there are keys that I want to be a combination (lines 7 & 9), I'm not sure if I have the right code grammar for it, I simply copied the example that looks to have a combination as far as I can understand.

The last portion:

1. setxkbmap -device $remote_id -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i $remote_id -synch - $DISPLAY 2>/dev/null

All I can get from this is that this is the line that activates the execution process of the file. Understandable that this is actually needed, otherwise all the script would do is create a file with key code stuff in it. As far as I understand the tutorial, everything with "$" is suppose to be customised. Which is confusing since there is also a "$DISPLAY" which makes me doubt whether I have that right or not. Nonetheless, my customisation:

1. setxkbmap -device 19 -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | xkbcomp -I/tmp/xkb -i 19 -synch - $DISPLAY 2>/dev/null

 

[Sasha-Jen]

there are some options available within xrandr to experiment with a custom resolution

In searching I've come across this command:

xrandr --output DVI-I-1 --scale 1x1

Where adding decimal fractions lowers the scale, however the main monitor starts to "bleed" onto the TV rather than make a black border around the TV output.

 

[Sasha-Jen]

Overscan. The term for what the TV is doing is overscan.

As to the scripting: does what I'm doing have to be in this xinitrc file? If I'm also going to want a start-up script for all these changes I want permanent (I've put that part on hold until I've solved everything else at least for temporary single-sessions), can I not just have one script for everything on start-up?

I've never done this stuff before, so it is all new to me.

 

[Sasha-Jen]

I have found this tutorial: https://ictsolved.github.io/remap-key-in-linux

The method 2 within it is the same method as the first tutorial I am using for the remote remapping. While there are several differences, one of note is the directories between them are different, and both are different than the directory my X11 stuff is in:

Tutorial 1: /tmp/xkb/symbols
Tutorial 2: /usr/share/X11/xkb/symbols/

My xinitrc file (that I've edited the script into): /etc/X11/xinit/xinitrc
My xkb directory: /etc/X11/xkb

This has led me to conclude that I need to customise the directory in the script. There are 2 portions of the script that need to be changed (going by my previous break-down of the script); here's how they now look in my script (with added line numbers for referencing again):

1. mkdir -p /etc/X11/xkb/symbols
2. cat >/etc/X11/xkb/symbols/custom <<\EOF
3. xkb_symbols "remote" {
4. key <AB04> { [ AB05 ] };
5. key <AD08> { [ DOWN ] };
6. key <SPCE> { [ AD03 ] };
7. key <AB05> { [ LCTL, AB01 ] };
8. key <RTRN> { [ UP ] };
9. key <AB01> { [ LCTL, AB01 ] };
10. key <AB07> { [ LCTL ] };
11. key <AD10> { [ SPCE ] };
12. key <AD07> { [ LALT ] };
13. };
14. EOF

1. setxkbmap -device 19 -print | sed 's/\(xkb_symbols.*\)"/\1+custom(remote)"/' | $"/' | xkbcomp -I/etc/X11/xkb -i 19 -synch - $DISPLAY 2>/dev/null

No other part of the script has been altered since my last update of it. My uncertainty over certain portions remain as described previously.

One other thing I think is worth nothing is the latter tutorial is for a universal key remapping while the former is for device-only. This is helpful to see what the latter is missing from the former. While they are slightly different anyway, I think it is worth nothing that the latter has no device id portion (the first section of the first tutorial script).

Is there someone who is known for routinely helping with scripts that can be mentioned to have a look and potentially help with this on these forums?

Thanks.

edited addition: unrealted, but I'll share how liberating it feels to see that I have available updates and I have control of when they install. Screw windows 10.