Finally replaced the old display with a new touch display in my VF-1 inspired home cockpit panel.

The old display was salvaged from a laptop years ago and while it was working fine it also has a very bad viewing angle. I also got really tired of it’s glaring reflections so I experimented with an anti glare foil. This reduced the reflections a lot (worth every cent) but couldn’t help with the bad viewing angle, of course. I now had an idea how this could look though so I decided to buy into a replacement kit.

The new display is the N173HCE-E31, a 17.3" with a resolution of 1920x1080. The touch controller registeres as a USB HID pointer/mouse by ILITEK and is basically sitting on top of the display. The kit included a PCB, that was advertised as VS-RTD2556HC-V2 controller by VSDISPLAY but came without any data sheet and I have no idea who really made this.

Thing is this PCB runs very hot and the noted input voltage isn’t explicitly stated. An attached image suggested to use an USB PD power supply without 20V so I was looking for it’s datasheet to check if I was just holding it wrong. Picture me surprised but VSDISPLAY does not list this particular configuration in it’s datasheets. I contacted them via mail and they confirmed that this is not theirs. Theirs is apparently also strictly 5V/12V so that matches the picture I get.

Mine is equipped with the IC RTD2556VD that does not match the list of supported ICs. Theirs has 2556TE_R20.1 printed on the PCB. Mine has 2555TF_R30.1 printed on. It’s like 99% similar but differently routed. It also mentions E470791 JPX-D which seems to point to the PCB manufacturer Dongguan Jingweixin Circuit Co Ltd but that is where my GoogleFu left me. I did also find the very same pictures on other offers, each stating a completely different controller model 🤷

Anyway. I tried different configurations and while it works with 5V at ~2A I feel way more comfortable with 12V at ~0.8A on full brightness + blue color. I also attached a passive cooling block I had laying around and slapped a fan on top. Now it’s only “comfortable” warm to the touch after running for an hour.

Sadly I do not have any device with DP ALT providing more than 5V and the PCB will always switch down to 5V the moment the USB-C dedicated for the display signal is used as well, even when a proper USB PD power supply is attached on it’s dedicated power connector. I could only keep it at 12V with my VITURE USB-C XR charging adapter, which can indeed provide 12V and more via USB-C while still allowing DP-ALT + USB2. There went my plans to only have a single cable for all, DPPD and the USB2 lanes for the ILITEK pointer, because I really do not want to block this adapter all the time.

So now I have a dedicaded USB PD power supply at 12V connected, a HDMI connection for the display and an additional USB2 for the touchpanel pointer – and on top of that the little fan, that I simply connected to the micro USB2 socket on the PCB to provide it with 5V.

This also means that my Linux PC can not know that both, touch panel pointer and display, belong together. As a result all touch panel inputs were all over the place and not limited to a single display. Apparently KDE has an option in it’s graphical settings where this can be easily configured. Gnome does not [yet?] have such an option in it’s graphical settings. There is however a way to enforce the mapping of the touch panel in Gnome too! And while the real manufacturer for the controller of the new display is still a mystery to me I found the following snippet in my monitor configuration $HOME/.config/monitors.xml after plugging the controller in:

<monitorspec>
    <connector>HDMI-2</connector>
    <vendor>RTK</vendor>
    <product>0x2555</product>
    <serial>0x20230705</serial>
</monitorspec>

The touch panel is, according to lsusb, connected as ID 222a:0001 ILI Technology Corp. Multi-Touch Screen. Armed with that knowledge I can limit it’s input with gsettings to this specific display:

gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/222a:0001/ output "['RTK', '0x2555', '0x20230705']"

Works like a charm but what a mess. I still wish I had a data sheet for this so if you know more kindly drop me a comment!

The last thing to fix was the already mentioned reflective glare. For this I went with a screen protector by BROTECT (that name still makes me laugh), that promises beside anti scratch also an anti glare effect without limiting the view angles (some foils do this to enhance privacy).

Attaching the foil was straight forward. The trick is to make sure that not a single dust particle is around during the process. To help with this I used an air humidifier to raise the humidity in the room before I even started. After that I removed the protective cover from the display and started slapping on the foil with the provided mounting card (yay, cardboard again). This was the very moment one of my curious cats decided to investigate my actions and jumped onto the table almost giving me a heart attack. The last thing I needed was cat hair all over the place and indeed after a lot of hissing I had to make good use of the also provided adhesive sticker to catch all dust particles in the last corner. Cats!

The end result is like night and day. I do no longer see any light sources or myself clearly reflected on the display. The touch panel is still accepting inputs just fine and the colours look very bright from any angle, especially with HDR enabled. This will also ease it’s cleaning because the cockpit panel is collecting dust like crazy due to the gradient of the panel. I usually use a vacuum cleaner for this and the foil will help a lot to avoid scratches.

Replacing the old display was also a task on it’s own. The old screws didn’t fit, of course, so I kinda had to build little adapters from leftover angle and wood pieces. Very ugly but good enough – this is just a toy after all 🤓

Ah yes and now that I have a touch panel I also have to rewrite my HUD app, of course 🙃

Enforcing a touchscreen mapping in GNOME (who-t.blogspot.com)
Touchscreens are quite prevalent by now but one of the not-so-hidden secrets is that they're actually two devices: the monitor and the ac...

Hell yes, https://who-t.blogspot.com/2024/03/enforcing-touchscreen-mapping-in-gnome.html just solved my problem to limit a to a single display in . While it is detected just fine it’s input was all over the place of my 4 displays when that should only work for a single display. Apparently has something in it’s settings where this can be easily configured. Gnome does not [yet?] have such an option in settings.

There is however a way to enforce the touchscreen mapping in Gnome too!

The real manufacturer for the controller of my new display here is still a mystery to me. Snippet from my $HOME/.config/monitors.xml is as follows:

<monitorspec>
<connector>HDMI-2</connector>
<vendor>RTK</vendor>
<product>0x2555</product>
<serial>0x20230705</serial>
</monitorspec>

The touchscreen comes back as an ILITEK-TP though and according to lsusb is it connected as ID 222a:0001 ILI Technology Corp. Multi-Touch Screen.

Armed with that knowledge I can limit it’s input with gsettings:

gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/222a:0001/ output "['RTK', '0x2555', '0x20230705']"

Works like a charm!

I like my desktop but some things really drive me mad. I recently switched to an AM5 board (yeah yeah first world problems) which came with an integrated adapter. Which sucks. Badly. Dunno if it’s the driver or interference from the board itself or due to the case shielding the signal. I don’t really care as well. It can however not be deactivated in the UEFI settings.

I’m using a BT adapter plugged in via USB for years now and moved this over to my new system. It works _excellent_ even with multiple devices. I get clear sound without crackling on my headphones, which is what I really care for to stay “in the zone” for work.

Alas Gnome does not let you choose which BT adapter is used – unlike we know this e.g. from the NetworkManager. Apparently it even defaults to the _first_ adapter it finds, which is by design the integrated one – that I do not want in my case. I can basically only tell them apart by their addresses that I can obtain via the hcitool command:

$ hcitool dev
Devices:
	hci1	10:B1:DF:AA:63:50
	hci0	00:1A:7D:DA:71:06

The full details on this can be extracted from this [closed] 5 years old feature request: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/263 (let user choose one bluetooth device from several in gnome control center)

And everything mentioned there is still true and while I usually can understand Bastien’s reasoning in this case I can’t. Alas not all is lost. It’s a little tedious but the following example script was added to unbind an adapter:

#!/bin/sh

ADAPTER_TO_DISABLE=${1:-hci0}
SYSFS_PATH=/sys/class/bluetooth/$ADAPTER_TO_DISABLE

if [ ! -h $SYSFS_PATH ] ; then
	echo "Could not find adapter $ADAPTER_TO_DISABLE"
	echo "Usage: $0 [hciX]"
	exit 1
fi

USB_DEVICE_PATH=`realpath $SYSFS_PATH/device`
USB_DEVICE=`basename $USB_DEVICE_PATH`
echo $USB_DEVICE > $SYSFS_PATH/device/driver/unbind

The adapter will be back on the next reboot so it’s a little tedious but at least I can now kill the malfunctioning one. It’s a hammer to a nail but it works. Put in a script it may be called like this:

sudo unbind-bluetooth-driver.sh hci1

Oddly enough something in the gnome-shell extension acts up now and duplicates the device list.

BT quick selection modal of Gnome duplicating the list of known devices

I can live with that though and it may even be fixed with a more recent version already. I’m still on 44.9 and somewhat behind on this currently.

So I got a stuck from time to time. No mailbox or calendar would load and Evolution eventually claim that it can’t connect to the accounts. Turns out this is quite literal. I’m on and that has a framework for single sign-ins called GNOME Online Accounts or GOA for short (that thing I wish the Nextcloud client would USE too).

Apparently this happens _sometimes_ after standby/suspend, that I use quite often to save on power, so it was really hard to find. Looks like the goa-daemon gets stuck on resume. There is nothing in the journal or so.

Anyway, it can be restarted quite easily by executing `/usr/libexec/goa-daemon --replace` manually. So basically what happens on login. The effect on Evolution is instant. Yay, ~~spam~~mails again!

Today I scratched an itch I had with and . Every time I run it on my PC I have to drag around the window until it fills my 3 displays setup. It’s tricky because it’s a grown installation and the displays have different resolutions.

Gnome has smart borders auto-sizing windows when you come close to a border. Usually that’s awesome but in this case it’s not. wmctrl to my rescue!

Find out about current window position when satisfied: wmctrl -G -l -x

Use that information for a one liner script: wmctrl -x -r code.Code -e 0,0,109,5276,1136

This will do until I get a 4k display or learn how to auto-run this snippet on the launch of vscode (like I do this with RisingWorld to force semi borderless fullscreen) 🤣

Integrate with GNOME Online Accounts Single Framework · Issue #2550 · nextcloud/desktop (GitHub)
GNOME has a feature for managing online accounts in one place ( GnomeOnlineAccounts | GOA). In it's current state Nextcloud is supported and it can read calendar, contacts and documents (as in ...

GNOME has a feature for managing online accounts in one place ( GnomeOnlineAccounts | GOA).

In it’s current state Nextcloud is supported and it can read calendar, contacts and documents (as in providing a quick mount option in the file explorer): https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Providers

This way account credentials can be shared and are configured and managed in one place where they can be requested by an application. The communication is done via D-Bus.

Currently I have to configure my accounts in two places, the nextcloud-client and in GOA, to get a Nextcloud server tightly integrated into my system and while the passwords end up in the same place (gnome-keyring) it’d be more user friendly to share this from a common ground instead of having to configure this twice for each Nextcloud account.

There’s a weird issue with (snap) on that starts when using voice chat causing really bad lag and short freezes (input, rendering, everything) that became worse over time. My journal filled up with looping messages from appindicator causing this.

appindicatorsupport(at)rgcjonas.gmail.com[2514]: discord1, Impossible to lookup icon for 'discord1_12-panel'

Followed by a JS exception and trace:

JS ERROR: Exception in callback for signal: icon: Error: Argument 'filename' (type filename) may not be null

When I finally found the cause of this I went on looking for a solution and it seems like the unsung hero @3v1n0 fixed this long standing bug like 8 days ago: https://github.com/ubuntu/gnome-shell-extension-appindicator/commit/745c66a73e0a15a870e92e5aa461e2e9e646b899

Here is a more coherent report on this: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-appindicator/+bug/1849142

Fun thing is: I only have that indicator because Discord would eventually crash without trying to access this.

Now it’s patched and gone – back to 😁