On Wed, Apr 11, 2018 at 02:09:29PM +0300, Heikki Krogerus wrote: > On Wed, Apr 11, 2018 at 08:28:44AM +0000, andrey.ara...@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.kroge...@linux.intel.com> > > wrote: > > > > > On Tue, Apr 10, 2018 at 09:05:07AM +0000, andrey.ara...@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, -- heikki _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
