jglathe
external screen at 640x480
Now that we have the "screen never works" (#35) fixed, I thought I'd follow up on the issue that sometimes external screens are not detected properly and show tiny resolution. On my screen at home, this happens in about 30% of the cases and unplugging/replugging usually fixes it. At my office, I seem to encounter this less frequently, but I now have a screen where it repdroducably happens all the time. This is interesting, because it's a floating desk office and the screens seem to be identical.
Here are the details:
% swaymsg -t get_outputs
[internal skipped]
Output DP-2 'Unknown Unknown Unknown'
Current mode: 640x480 @ 59.940 Hz
Power: on
Position: 1599,0
Scale factor: 1.000000
Scale filter: nearest
Subpixel hinting: unknown
Transform: normal
Workspace: 3 mail
Max render time: off
Adaptive sync: disabled
Allow tearing: no
Available modes:
640x480 @ 59.940 Hz
1024x768 @ 60.004 Hz
800x600 @ 60.317 Hz
800x600 @ 56.250 Hz
848x480 @ 60.000 Hz
Dmesg from unplugging/replugging:
[ 8403.830535] usb 6-1: USB disconnect, device number 8
[ 8403.830554] usb 6-1.4: USB disconnect, device number 9
[ 8403.848169] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=1, orientation=1
[ 8403.848177] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=1, orientation=1
[ 8403.854086] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=0, altmode=1, orientation=1
[ 8403.854802] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=0, altmode=1, orientation=1
[ 8403.855225] fda000.phy-mux: qmp_combo_mux_set() enter mode=0, altmode=1
[ 8403.855229] qcom-qmp-combo-phy fda000.phy: typec_mux_set: DP PHY is still in use, delaying switch
[ 8403.858674] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=0, altmode=1, orientation=1
[ 8403.858677] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=0, altmode=1, orientation=1
[ 8408.140187] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.140964] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.141416] fda000.phy-mux: qmp_combo_mux_set() enter mode=1, altmode=0
[ 8408.141424] qcom-qmp-combo-phy fda000.phy: typec_mux_set: switching from qmpphy mode 1 to 2
[ 8408.144319] fda000.phy-mux: qmp_combo_mux_set() exit mode=1, new_mode=2, altmode=0
[ 8408.147513] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.147517] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.487961] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.487982] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.487991] fda000.phy-mux: qmp_combo_mux_set() enter mode=1, altmode=0
[ 8408.487998] qcom-qmp-combo-phy fda000.phy: typec_mux_set: same qmpphy mode, bail out
[ 8408.493703] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.493722] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.671435] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.671455] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.671464] fda000.phy-mux: qmp_combo_mux_set() enter mode=1, altmode=0
[ 8408.671471] qcom-qmp-combo-phy fda000.phy: typec_mux_set: same qmpphy mode, bail out
[ 8408.674542] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.674547] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.797567] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.797587] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.798399] fda000.phy-mux: qmp_combo_mux_set() enter mode=4, altmode=0
[ 8408.798411] qcom-qmp-combo-phy fda000.phy: typec_mux_set: switching from qmpphy mode 2 to 1
[ 8408.798915] fda000.phy-mux: qmp_combo_mux_set() exit mode=4, new_mode=1, altmode=0
[ 8408.799182] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.799187] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.799191] fda000.phy-mux: qmp_combo_mux_set() enter mode=4, altmode=0
[ 8408.799195] qcom-qmp-combo-phy fda000.phy: typec_mux_set: same qmpphy mode, bail out
[ 8408.802024] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.802028] fda000.phy-switch: qmp_combo_switch_set() enter new_orientation=1, altmode=0, orientation=1
[ 8408.826601] qcom_battmgr.pmic_glink_power_supply pmic_glink.power-supply.0: unknown notification: 0x283
[ 8408.903236] usb 6-1: new high-speed USB device number 10 using xhci-hcd
[ 8409.028782] usb 6-1: New USB device found, idVendor=0451, idProduct=8142, bcdDevice= 1.00
[ 8409.028801] usb 6-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 8409.028806] usb 6-1: SerialNumber: 89040061B27E
[ 8409.063340] hub 6-1:1.0: USB hub found
[ 8409.063395] hub 6-1:1.0: 4 ports detected
[ 8409.071470] [drm:msm_dp_bridge_get_modes [msm]] *ERROR* failed to get DP sink modes, rc=0
[ 8409.413265] usb 6-1.4: new full-speed USB device number 11 using xhci-hcd
[ 8409.504009] usb 6-1.4: New USB device found, idVendor=043e, idProduct=9a39, bcdDevice= 2.03
[ 8409.504046] usb 6-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8409.504051] usb 6-1.4: Product: USB Controls
[ 8409.504056] usb 6-1.4: Manufacturer: LG Electronics Inc.
[ 8409.504060] usb 6-1.4: SerialNumber: 109NTXRJN562
[ 8409.609761] hid-generic 0003:043E:9A39.0015: hiddev1,hidraw5: USB HID v1.11 Device [LG Electronics Inc. USB Controls] on usb-xhci-hcd.4.auto-1.4/input0
[ 8409.610545] cdc_acm 6-1.4:1.1: ttyACM0: USB ACM device
If there is anything I can do to help track this issue down, or fix it, please let me know!
Well this will be a tough one. It is a timing issue IMO, with connections to dp and msm drivers. But we've solved quite a few things already, maybe this one is in range.
Adding some of my experience here. I am using a USB-C monitor (Dell U2723QE). After every reboot, I will need to replug the USB-C cable ~10 times into different ports on the devkit. Sometimes the display works but not the USB hub, sometimes the USB hub works but not the display, a few times it stuck with no EDID and 640x480 as well. Sometimes after the system sleep, I need to try everything again or reboot the system. And since the system is not that stable overall, sometimes it will reboot itself for no obvious reasons. Anyway, I am planning to buy a USB-C to DP cable and connect the hub to USB-A separately, in this way it might be easier lol. I understand there still are a lot of things that need to be implemented here (I am waiting for DP MST as well, FYI this WIP patch). Hopefully we can get more and more things to work properly.
Following up on this: today it took ~20 tries to get the screen (with the correct solution) just for the first time. Since this also happens after energy saving, I have multiple of these plug-out-replug session every day, resulting in 10-30 times putting in the USB-C and out.
Since USB-C is also power, this results in very many very short charging cycles which can't be good for the battery...
Anyway, anything I can do to help move this forward? Is there a chance that EL2-based boot will be better at this?
Since USB-C is also power, this results in very many very short charging cycles which can't be good for the battery...
I think your best bet for now is to use separate cables for power, USB, and display. After connecting the USB hub separately and the display via USB-C to HDMI, it usually takes at most two tries for the display to work. It still crashes randomly and needs to be redone, but it’s manageable. My main concerns now are the lifespan of the USB-C ports and the fact that the keyboard won’t wake the system—though the power button does.
Is there a chance that EL2-based boot will be better at this?
Looking at the commits, maybe not. I was hoping for 6.17 and some new patches currently pending on Patchwork but there seems to be some problems on 6.17 as well.
EL2 doesn't change much. What may change a bit is enabling the HDMI port on the device. @stephan-gh did enable it on some X1E hardware, so the chances are quite good. didn't come around to try it out yet, tbh. would this solve the immediate issue, although different connector?
Thanks for your help!
I think your best bet for now is to use separate cables for power, USB, and display.
How would I do that, if I only have two USB-C? And sometimes switching to a different USB-C port is the only way to get the display to work again... I also never ever have problems getting power over USB-C or the peripherals (although integrated into the screen); they always work. It's just the display that often does not. But my screen also has a setting to power the USB-C even if the screen itself is not used.
It still crashes randomly and needs to be redone, but it’s manageable
I don't really experience crashes/reboots anymore. At most once a month maybe.
And once the screen works, it also keeps working until it is disconnected or goes into powersave.
Looking at the commits, maybe not. I was hoping for 6.17 and some new patches currently pending on Patchwork but there seems to be some problems on 6.17 as well.
😿
What may change a bit is enabling the HDMI port on the device. @stephan-gh did enable it on some X1E hardware, so the chances are quite good. didn't come around to try it out yet, tbh. would this solve the immediate issue, although different connector?
Yeah, if I can leave the usb-c plugged in for power and hub, I could attach the screen over HDMI, that would be totally fine for my home office setup!
Which laptop model do you use @h-2
T14s 64GB
How would I do that, if I only have two USB-C? And sometimes switching to a different USB-C port is the only way to get the display to work again...
T14s 64GB
Looking at the ports and I agree what @jglathe is suggesting here. Maybe even USB C for power (from adapter), USB A for the USB hub (I guess 10Gbps is good enough) and HDMI or the other USB C for the display, if that's not too much trouble.
For me, as long as the USB C is connecting only display (USB C to HDMI only hub, or USB C to DP cable). After a reboot, most likely you don't need to switch port, just replug the cable and wait 5s. The display should come back. Sleeping also causes some problems for me, not sure what to do as well, so many times I would simply reboot again.
As for the HDMI, if you are willing to experimenting on the device tree a bit, you should definitely try that patch. Since T14s only has two USB C ports, it makes sense the HDMI is coming from the third DP/USB C out.
I had it working on T14s and was happy. Then I tried V3 of that patch 😢 You will not be happy with it on 6.16, needs 6.17rc. I'm struggling a bit to get onto 6.17 either, a lot (like, A LOT) to rebase into refactored portions which is not really fun. I guess I will reactivate the V1 patch if I find the commit and upload it as 6.16-el2-jg-5.
Hey Jens, I've got 6.17 to work using the patches here: https://git.launchpad.net/~ubuntu-concept/ubuntu/+source/linux/+git/plucky/log/?h=qcom-x1e-6.17. I just rebased it onto 6.17rc4, updated x1e80100.dtsi and the devkit dts. It works great, feels much more stable than 6.16 in general. I rarely need to replug my USB C cable (given mine is DP only right now). I actually mapped a keybind on sway just to power toggle the display, it helped a lot when the display is totally blank after sleep. If using USB and DP on the single cable then sometimes it is still acting weird. Hopefully this helps!
Thanks for your work on this! I am back from vacation and could potentially try new kernel images but won't have time for extensive tinkering before end of next week (because of work backlog).
I guess I will reactivate the V1 patch if I find the commit and upload it as 6.16-el2-jg-5.
That would be amazing! Are there instructions anywhere for migrating to el2, or do I just need to load the respective kernel from grub?
I will write up an updated how-to prob. today. My T14s is now in the state where reboot lands the system in the same selected system again, also when it's EL2. ToDo is some scripting to generate the desired menu entries.