On Wed, Apr 11, 2018 at 02:09:29PM +0300, Heikki Krogerus wrote:
On Wed, Apr 11, 2018 at 08:28:44AM +0000, andrey.arapov@nixaid.com wrote:
Thank you for the insights, Heikki!
Please find the acpi.dump.tgz file is a attached.
I do not have the USBC* and INT3515* devices,
OK. That means we don't have any way to interface with the USB Type-C ports directly unfortunately. The ports are quite simply not visible to us. We can't do anything from USB side.
The problem is in any case a graphics problem, so maybe it's better to let those guys take a look at this. I think this MacBook Pro has AMD GPU, so adding AMD driver maintainers and lists.
Sorry Andrey, the previous mail did not get to you. I managed to change your email address somehow. :-)
so I have attached the following file as well:
# ls -1 /sys/bus/acpi/devices/*/status | while read dev; do echo $dev: $(cat $dev); done | gzip -c > /tmp/all-device-status.log.gz
KR, Andrey Arapov
April 10, 2018 4:35 PM, "Heikki Krogerus" heikki.krogerus@linux.intel.com wrote:
On Tue, Apr 10, 2018 at 09:05:07AM +0000, andrey.arapov@nixaid.com wrote:
Dear Linux Kernel Devs,
I have recently got a Lenovo ThinkVision X1 27" monitor, it is connected to my laptop over a USB-C cable (DisplayPort).
This monitor has a built-in USB hub with a toggle button, when pressed it shows two options on the screen:
Press USB Switch to toggle between: A) 3840x2160 UHD USB 2.0 B) 1920x1080 FHD USB 3.0
By default it is always set to FHD, which is why Linux sees the 1920x1080 as a maximum possible resolution.
Whenever I am changing it to the UHD, Linux is not changing the resolution to 3840x2160, instead it sets to somewhere around 2560x####.
To work this around, I am running the following commands manually:
xrandr --newmode "3840x2160_60.00" 533.25 3840 3888 3920 4000 2160 2163 2168 2222 +hsync -vsync xrandr --addmode DisplayPort-2 3840x2160_60.00 xrandr --output DisplayPort-2 --mode 3840x2160_60.00
Then, when I was trying to switch it back to FHD and again back to UHD, sometimes it causes a kernel panic. The panic also happened when I was plugging the cable in/out and back again. What I was able to spot is that the last unloaded kernel module was usbhid.
Please advise, what can I try to help investigating this issue further?
I have attached the output from "dmesg -T" command as "4.16.1-dmesg.txt" file. The logs are related to when the monitor was connected via a USB-C cable to a DisplayPort-2, the default resolution picked was FHD (USB 3.0) and then I have pressed the toggle button to use UHD (USB 2.0), then have applied the "xrandr" commands and have closed the lid of my laptop so I would be using my monitor as a primary display.
The board seems to support Thunderbold, however, in this case my guess is that the monitor is actually using just the DP alternate mode (Thundebolt can pipe DisplayPort protocol).
I'm guessing the problem is related to the DisplayPort lane counts. With the highest resolutions you need all four lanes, but if you want to use USB3 with USB Type-C connectors at the same time, two have to be allocated for USB3 leaving only two for DisplayPort allowing lower resolution. The problem is that the GPU drivers need to know how many lanes the DisplayPort has in use. That information will in normal case come from USB Type-C drivers. Unfortunately we do not have support for that in Linux kernel yet, but I have made a proposal for a solution.
Let's start by checking details of your board. Can you send us acpidump output?
% acpidump -o <filename>
Also, please check the status of these acpi devices:
% cat /sys/bus/acpi/devices/USBC*/status % cat /sys/bus/acpi/devices/INT3515*/status
Cheers,