Bug 196185 - displayport uld does not power on display like uldfb does
Summary: displayport uld does not power on display like uldfb does
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Console/Framebuffers (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: James Simmons
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-25 03:35 UTC by Robert White
Modified: 2018-08-16 10:56 UTC (History)
0 users

See Also:
Kernel Version: 4.11.7
Subsystem:
Regression: No
Bisected commit-id:


Attachments
kernel backtrace (6.12 KB, text/plain)
2018-08-16 10:56 UTC, Robert White
Details

Description Robert White 2017-06-25 03:35:32 UTC
I am using a MIMO 720S.

The display initializes correctly at the BIOS level; that is it powers up (blue power light) and then does the video self-test cycles (various patterns and colors).

When the linux kernel loads the display goes dark (probably because the power on the hub cycles).

If the old "udlfb" driver is loaded then the screen comes back on solid-green. Then it's pretty useless inside Xorg et al since the frame buffer modes don't mix well with DRI.

If the new "udl" driver is loaded then the screen stays dark, but all the plumbing is visible using the xrandr command. e.g.

# xrandr --setprovideroutputsource modesetting Intel
# xrandr
(... elided for brevity ...)
DVI-I-1-1 connected (normal left inverted right x axis y axis)
   800x480       61.88 +

Pressing the power button on the display makes the blue light come on momentarily but then it drops off.

I think it's just not being sent enough power. The bMaxPower value is only 50mA according to the USB tree.
Comment 1 Robert White 2017-06-25 03:46:25 UTC
Additional information...

If I boot up with udlfb the screen powers up. If I then "rmmod udlfb; rmmod uld; modprobe udl" the screen will turn off when the udl driver loads, so it's definitely something the uld driver is doing at init time.
Comment 2 Robert White 2018-08-16 10:56:02 UTC
Created attachment 277887 [details]
kernel backtrace

This backtrace happens four times when I plug in the device. I can't find the get that matches the problematic put.

Note You need to log in before you can comment on or make changes to this bug.