Initial Librem5/Nexdock360 impression

I only have an older NexDock model here for which I also need an EDID override ( and with that it looks like:

gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/1a86:e2e4/ output "['Unknown', 'Linux FHD', 'Linux #0']"

If you run that merge request and enable debugging via G_MESSAGES_DEBUG=phoc-output,phoc-seat it will print something like this: in the journal and you can grab the information from there.

For my HP monitor I used:

gsettings set org.gnome.desktop.peripherals.tablet:/org/gnome/desktop/peripherals/touchscreens/1b96:0f01/ output "['Hewlett Packard', 'HP w2207', 'CZD74909W7']"

You can also fetch the information via edid decode:

edid-decode /sys/devices/platform/soc@0/32c00000.bus/32e00000.display-controller/drm/card2/card2-DP-1/edid

If it worked you’ll see something like

Mapping touch device USB2IIC_CTP_CONTROL to DP-1

in the logs.

1 Like

Thank you. My NexDock360 has model# NDK2113. This can be found in the OSD menu under “info”.

The touch device has USB ID 27c0:0819 Cadwell Laboratories, Inc. WingCoolTouch.

$ libinput list-devices
Device: WingCoolTouch WingCoolTouch
Kernel: /dev/input/event12
Group: 5
Seat: seat0, default
Size: 216x91mm
Capabilities: touch
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: identity matrix
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a

Not exactly, more 294x175mm. But it nevertheless is the right device. I validated this by listing its events.

I could not spot EDID issues in the log. Beside, perhaps:

colord[990]: failed to get edid data: EDID length is too small
pureos gsd-color[873]: unable to get EDID for xrandr-DP-1: unable to get EDID for output
pureos gsd-color[873]: unable to get EDID for xrandr-DSI-1: unable to get EDID for output

but i believe, that might be a very different issue.

I tried edid-decode and got some proper list. A touch device is not mentioned there.

To proceed further, i guess, i need to translate your MR first. I have no build environment set up, yet, but i’ll give it a shot. Thx, again.

216x91mm maybe this is the little square that triggers the options in the nexdock?

@uzanto Unlikely, the square is about 80x50mm. Not even sure where libinput got these values from. I listed the usb device using usb -v but the report descriptors are blocked while the driver (usbhid) sits on it…

echo -n 3-1.2:1.0 >/sys/bus/usb/drivers/usbhid/unbind
echo -n 3-1.2:1.1 >/sys/bus/usb/drivers/usbhid/unbind

Then, finally lsusb -v -d 27c0:0819 reports:

Item(Global): Unit, data= [ 0x11 ] 17
System: SI Linear, Unit: Centimeter
Item(Local ): Usage, data= [ 0x30 ] 48
Item(Global): Physical Minimum, data= [ 0x00 ] 0
Item(Global): Physical Maximum, data= [ 0x79 0x08 ] 2169
Item(Main ): Input, data= [ 0x02 ] 2
Data Variable Absolute No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile Bitfield
Item(Global): Logical Maximum, data= [ 0x7f 0x25 ] 9599
Item(Global): Physical Maximum, data= [ 0x8a 0x03 ] 906
Item(Local ): Usage, data= [ 0x31 ] 49

So the geometry info appears to come from the USB descriptor, which is simply wrong at that point. As long as the physical size is not used, it does not matter, though.

What does matter, and so i understand @guido.gunther’s idea, is how the touch screen device is seen by the L5. From the USB-descriptors it is just a digitizer on USB, which delivers absolute positions but yet unrelated to any display.

Now where is the origin? Because the USB descriptors do not describe this, L5 has to guess, and it guesses it must the origin of its own screen causing the effect first described here as:

But contrary to the first impression, the touches are not erratically, but proportionally mapped to the L5 screen. E.g. left-upper and right-lower corner of the NexDock’s touch screen map to the respective corner of L5’s screen. Because the touches do not affect the cursor, this effect is not immediately visible, but one can validate this with a bit care and i did. The touches affect the controls and the windows boarders.

For me, this establishes, that @guido.gunther’s suspicion is right. Thus all, L5 has to know, is that the digitizer’s (touch screen) positions are to be interpreted as related to the NexDock’s screen. And that is the semantic of the setting Guido describes in his MR.

This leave to actually try it…

1 Like

Debugging is not on by default. You need to enable that by e.g. adding this


to /usr/bin/phosh (you can also do that via unit override but this is usually quickest). If someone wants to do a script that fetches the information from edid-info and generates the proper gsettings command that would be welcome.

1 Like

wlr-randr gives you the information too:


DP-1 "Dell Inc. DELL U3219Q H1FH413 (DP-1)"

Dell Inc. is the vendor DELL U3219Q the model and H1FH413 the serial.

I get

DP-1 “Unknown NexDock 8R33926O00Q (DP-1)”
Physical size: 290x170 mm
Enabled: yes
1920x1080 px, 60.042000 Hz (preferred)
1920x1080 px, 60.000000 Hz
1920x1080 px, 59.939999 Hz (current)
1920x1080 px, 50.000000 Hz
1920x1080 px, 30.000000 Hz
1920x1080 px, 29.969999 Hz
1920x1080 px, 25.000000 Hz
1920x1080 px, 24.000000 Hz
1920x1080 px, 23.976000 Hz
1280x1024 px, 60.020000 Hz
1280x720 px, 60.000000 Hz
1280x720 px, 59.939999 Hz
1024x768 px, 60.004002 Hz
Position: 720,0
Transform: normal
Scale: 1.000000

which looks good for me with respect to the display modes you were concerned about.

Not concerned. It’s actually broken with older NexDock devices - good that it works for you.

So here we go. I tried to compile the phoc master branch on the L5 which was not difficult thanks to good readmes, but decided to install phoc_0.9.0+librem5ci332127.678a37b_arm64.deb for simplicity instead. After a reboot, this gives:

phoc[639]: Mapping touch device WingCoolTouch WingCoolTouch to DSI-1

But we want this to be on DP-1:

gsettings set org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/27c0:0819/ output "['Unknown', 'NexDock', '8R33926O00Q']"

… reboot (i could have better simply unplugged the NexDock perhaps) … and it works! Log says:

phoc[638]: Tracking config path /org/gnome/desktop/peripherals/touchscreens/27c0:0819/ for WingCoolTouch WingCoolTouch
phoc[638]: Input output mappings changed, reloading settings
phoc[638]: Looking up output Unknown/NexDock/8R33926O00Q
phoc[638]: Mapping touch device WingCoolTouch WingCoolTouch to DP-1

Thanks Guido!


I’ve bumped the logging message about new outputs to info level so they show up in the logs by default now:

Nov 11 11:55:20 nn106 phoc[2755]: Output 'DP-1' added ('Unknown'/'Linux FHD'/'Linux #0'), 500mm x 280mm

so they’re easy to grab.

1 Like

OMG, I installed the same deb, copied your command and it is working! I tried drawing on inkscape and it works wonderfully,
Strangely enough, ND touch input cannot scroll the applist (I can open it by pressing the arrow, scrolling open programs, but I cannot launch new ones, control the backlight slider… there are a few things that are not working, but overall it’s really nice to have touchscreen working, thanks @guido.gunther !)

1 Like

@nico202 The touch issue is likely - so not a new thing but something that happens in other situations as well. Need to look at it at some point.

1 Like

I can confirm that this is working for me, now I just need to make the display swapping plug and play without errors, it is any built in method to perform this @guido.gunther ? I mean that I want the L5 display going off and using the ND360 as only one, we were playing with Kanshi in this post but when you plug/unplug it usually crash phosh.

Things should work well when you leave the primary display on the phone (or move it back to the phone before unplug: Output placement needs somebody to implement - needs some discussion if that should be done in phoc or phosh).

…and allows me to unplug even when the primary display is on the external screen. I didn’t test very well yet, this mostly came about while looking at else.

1 Like

…also this might become a monologe: I’ve fixed the touch problems on the NexDock display as well ( and polished some more edges in phosh ( With that and one patch in phoc reverted to avoid a compositor crash when the shell locks ( things are pretty usable for me now. So once that is in released versions things should become pretty smooth.


Not necessarily. I for one was so happy, that you made the touch screen going, that i simply did not want to dare to steal more of your very precious developer cycles. :wink:

While testing with the NexDock360 i saw some problems that i could report at least:

If you want me, i can write down a more proper report into gitlab, with some suggestions, though i find it low priority right now, as it does not focus on the Librem5 but on the connection with another device.

Additionally, i noticed some glitches/errors on resolution setting and window sizing which should be of more general interest for any convergence use. To quickly summarize, there were:

  • sometimes changes in the Librem5 resolution (became highest) when unplugging sometimes. Nice, because one sees a lot, but fingers were far to big to control the screen.
  • size of windows was often not changed back to full-screen, then, making them difficult to control, too.
  • also unbalanced cursor/touch semantics. In the upper part of the window the cursor got moved with the touch, otherwise not.
  • Hmm, i saw a little unfilled damage at least once.

I’m not sure if these reports are new, helpful or welcome. But if you want, we can focus on any of the point you were fixing or on any of the points i listed above and i can offer to more carefully test the connect / disconnect operation if it helps.


@dort Thanks for the input. I agree on the priority but it’s always good to track issues:

sometimes changes in the Librem5 resolution (became highest) when unplugging sometimes. Nice, because one sees a lot, but fingers were far to big to control the screen.

That is basically a result of the fact that we don’t know the original devices “default” resolution and will be fixed with

size of windows was often not changed back to full-screen, then, making them difficult to control, too.

that would be a bug and should be filed at ideally with a good reproducer

also unbalanced cursor/touch semantics. In the upper part of the window the cursor got moved with the touch, otherwise not.

I don’t understand the exact problem here but maybe also file it with a description how to reproduce at the above URL (screenshots / videos also often help)

Hmm, i saw a little unfilled damage at least once.

That is known issue with multiple outputs (can’t find the issue atm)


Yep, so i see it, too. I’ll describe the points. Since i was already paging in the phoc sources for curiosity, it is nice to see that they might be phoc related.

What about the NexDock360/Librem5 screen blanking, power management stuff, btw? The point is, that the power management assumptions fail from both sides. When L5 turns off the screen (to save power) the ND first shows a white screen instead (to alert the user) and powers off after a while (to save power), finally leaving the L5 uncharged, though a power supply may be attached on the ND.

This is so wrong and sits so perfectly between all chairs, that i really love it.

Perhaps, i should first try to make a contact with NexDock about this point, because L5 cannot help it and could best work around the issue somewhat. Any other ideas, someone?

Did you get any information? (or answer at all)?

It doesn’t do anything unexpected or wrong. The L5 could help it: a workaround would be to only switch off the internal screen and whatever else is switched off when the power button is pressed. There could be a signal to the nexdock to keep it on.

Something like a special “docked standby” mode.