Re: Lenovo ThinkVision X1 27" USB-C occasionally hangs the kernel (usbhid) and isn't setting a proper resolution when USB 3.0 (FHD) switched to USB 2.0 (UHD)

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

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,

-- 
heikki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel