Bug 108502 - Invalid encoder after hotplug
Summary: Invalid encoder after hotplug
Status: RESOLVED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-19 18:25 UTC by Wolfgang Haupt
Modified: 2019-05-29 10:00 UTC (History)
2 users (show)

See Also:
i915 platform: KBL
i915 features: display/DP


Attachments
dmesg (231.41 KB, text/x-log)
2018-10-19 18:25 UTC, Wolfgang Haupt
no flags Details
Test Application Source (1.18 KB, text/x-c++src)
2018-10-19 18:26 UTC, Wolfgang Haupt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Haupt 2018-10-19 18:25:15 UTC
Created attachment 142105 [details]
dmesg

I'm working on hotplug support for linux/gbm in kodi.
Now I hit a roadblocker which looks like a driver issue to me.

I retrieve the hotplug info through a udev monitor and then I reinitialize the graphic system of the application.
Unfortunately I always get an encoder ID 0 and initialization of the drm/kms code fails.

I have attached a small test application, that can easily reproduce the issue.
These are the needed steps (for ubuntu):
sudo systemctl isolate multi-user.target
DISCONNECT HDMI
cd /path/of/testapp
./a.out
CONNECT HDMI

After this steps, if you stop the app and restart it you will always get an invalid encoder.
The kernel log also shows an issue with getting the edid infos from the i2c controller.

This state doesn't change until you do another hotplug or reboot the box.

I've tested this with kernel 4.17.12 and kernel 4.18.3 -> same results.

Attached is the source of my sample and the dmesg log with drm.debug=14.
Comment 1 Wolfgang Haupt 2018-10-19 18:26:44 UTC
Created attachment 142106 [details]
Test Application Source
Comment 2 Lakshmi 2018-10-24 09:36:42 UTC
Stan, any comments here?
Comment 3 Stanislav Lisovskiy 2018-10-24 11:48:19 UTC
(In reply to Lakshmi from comment #2)
> Stan, any comments here?

So far I only had time to run the program attached. For me it shows everything correctly - when I have dock two DP MST ports connected it shows connectors and encoder ids are not 0. For disconnected ones it shows zeroes. 

However as you know we have some bugs, which are only reproducible with certain hardware, so nothing new here.
Comment 4 Wolfgang Haupt 2018-10-24 12:38:46 UTC
(In reply to Stanislav Lisovskiy from comment #3)
> (In reply to Lakshmi from comment #2)
> > Stan, any comments here?
> 
> So far I only had time to run the program attached. For me it shows
> everything correctly - when I have dock two DP MST ports connected it shows
> connectors and encoder ids are not 0. For disconnected ones it shows zeroes. 
> 
> However as you know we have some bugs, which are only reproducible with
> certain hardware, so nothing new here.

What you say is correct, the case I want to make is like the following:
1) When nothing is connected it shows zeroes.
2) Keep program running
3) Plugin HDMI
4) Stop program
5) Start program -> encoders are still 0.

The state in (5) will not change no matter how often you stop/start the program.
You need to unplug/replug HDMI again to make it work.
This happens on Kaby Lake for me.


To me it looks like an issue if a user space programm has a file handle to /dev/dri/cardX and the state of HDMI goes from disconnected to connected.

Please let me know if you need further information.
Comment 5 Wolfgang Haupt 2018-11-08 17:18:23 UTC
What's the current status of this issue?
After https://bugs.freedesktop.org/show_bug.cgi?id=106291 was downgraded to low priority I managed to implement off-screen rendering in order to start kodi without a screen connected.
Now this issue, blocks me from auto switch into on-screen rendering.
It would be great if someone could pick it up.
Comment 6 Lakshmi 2018-11-28 09:24:11 UTC
(In reply to Wolfgang Haupt from comment #5)
> What's the current status of this issue?
Can you please reproduce this issue with latest drmtip? and attach the dmesg log with kernel parameters drm.debug=0x1e log_buf_len=4M.

Logs from latest drmtip will always help us in investigating/debugging this issue faster.
Comment 7 Ville Syrjala 2018-11-28 20:52:58 UTC
(In reply to Wolfgang Haupt from comment #4)
> (In reply to Stanislav Lisovskiy from comment #3)
> > (In reply to Lakshmi from comment #2)
> > > Stan, any comments here?
> > 
> > So far I only had time to run the program attached. For me it shows
> > everything correctly - when I have dock two DP MST ports connected it shows
> > connectors and encoder ids are not 0. For disconnected ones it shows zeroes. 
> > 
> > However as you know we have some bugs, which are only reproducible with
> > certain hardware, so nothing new here.
> 
> What you say is correct, the case I want to make is like the following:
> 1) When nothing is connected it shows zeroes.
> 2) Keep program running
> 3) Plugin HDMI
> 4) Stop program
> 5) Start program -> encoders are still 0.
> 
> The state in (5) will not change no matter how often you stop/start the
> program.
> You need to unplug/replug HDMI again to make it work.
> This happens on Kaby Lake for me.
> 
> 
> To me it looks like an issue if a user space programm has a file handle to
> /dev/dri/cardX and the state of HDMI goes from disconnected to connected.
> 
> Please let me know if you need further information.

The drm master is in charge of enabling/disabling displays. The first client to open the device node will automatically become the master. And afterwards as long as open fds remain fbdev/fbcon will not try to do anything with the displays. It's not clear from the above explanation whether all fds are getting closed or not. If they are not then the behaviour is as expected.

As far as hotplug support for kodi goes, you definitely don't want to rely on fbdev/fbcon to enable displays for you. You should be doing that yourself. fbdev might not even be enabled on the system.
Comment 8 Lakshmi 2019-02-22 07:38:21 UTC
Wolfgang, can you address Ville's comment 7.
Comment 9 Wolfgang Haupt 2019-02-22 12:02:38 UTC
(In reply to Ville Syrjala from comment #7)
> (In reply to Wolfgang Haupt from comment #4)
> > (In reply to Stanislav Lisovskiy from comment #3)
> > > (In reply to Lakshmi from comment #2)
> > > > Stan, any comments here?
> > > 
> > > So far I only had time to run the program attached. For me it shows
> > > everything correctly - when I have dock two DP MST ports connected it shows
> > > connectors and encoder ids are not 0. For disconnected ones it shows zeroes. 
> > > 
> > > However as you know we have some bugs, which are only reproducible with
> > > certain hardware, so nothing new here.
> > 
> > What you say is correct, the case I want to make is like the following:
> > 1) When nothing is connected it shows zeroes.
> > 2) Keep program running
> > 3) Plugin HDMI
> > 4) Stop program
> > 5) Start program -> encoders are still 0.
> > 
> > The state in (5) will not change no matter how often you stop/start the
> > program.
> > You need to unplug/replug HDMI again to make it work.
> > This happens on Kaby Lake for me.
> > 
> > 
> > To me it looks like an issue if a user space programm has a file handle to
> > /dev/dri/cardX and the state of HDMI goes from disconnected to connected.
> > 
> > Please let me know if you need further information.
> 
> The drm master is in charge of enabling/disabling displays. The first client
> to open the device node will automatically become the master. And afterwards
> as long as open fds remain fbdev/fbcon will not try to do anything with the
> displays. It's not clear from the above explanation whether all fds are
> getting closed or not. If they are not then the behaviour is as expected.
> 
> As far as hotplug support for kodi goes, you definitely don't want to rely
> on fbdev/fbcon to enable displays for you. You should be doing that
> yourself. fbdev might not even be enabled on the system.

(In reply to Lakshmi from comment #8)
> Wolfgang, can you address Ville's comment 7.

I wanted to answer that, but I don't understand the comment and lack knowledge on how to respond properly.
As soon as I found the time to update my kernel to the latest drm-tip and see if the issue
is still present, we can discuss it further.
I'm still looking for answers on how to properly support display hotplug in DRM/KMS.
As we directly talk via libdrm and have no compositor, I tried to look at weston's DRM/KMS backend, but
couldn't find reference code there as well.
Comment 10 Lakshmi 2019-03-25 11:53:14 UTC
Reporter, any results from latest drmtip?
Comment 11 Wolfgang Haupt 2019-03-25 13:08:01 UTC
Not yet, I'll most likely be able to update my kernel this week.
Comment 12 Wolfgang Haupt 2019-04-04 21:26:40 UTC
OK things have changed.
The bug reported seems to be fixed.

I have following behaviour now and wonder if this is expected:
1. Unplug HDMI
2. Run demo program
3. Plugin HDMI

As long as the program is running, the screen will not get active.
When I close the program (which will release the handle to /dev/dri/card0) the screen will become active.

Can anyone confirm that this is how it should be?
Comment 13 Lakshmi 2019-04-10 06:42:43 UTC
Stan, Can you confirm if the behavior is correct. If so, we can close this bug?
Comment 14 Stanislav Lisovskiy 2019-05-02 14:19:41 UTC
(In reply to Wolfgang Haupt from comment #12)
> OK things have changed.
> The bug reported seems to be fixed.
> 
> I have following behaviour now and wonder if this is expected:
> 1. Unplug HDMI
> 2. Run demo program
> 3. Plugin HDMI
> 
> As long as the program is running, the screen will not get active.
> When I close the program (which will release the handle to /dev/dri/card0)
> the screen will become active.
> 
> Can anyone confirm that this is how it should be?

I think this is expected behavior, as you get DRM resources and not releasing them. Those get released automatically once you the process terminates then.

If you want to have your screen active, when that program is still running
you need to call drmModeFreeResources before the while cycle.
Comment 15 Lakshmi 2019-05-29 10:00:45 UTC
(In reply to Stanislav Lisovskiy from comment #14)
> (In reply to Wolfgang Haupt from comment #12)
> > OK things have changed.
> > The bug reported seems to be fixed.
> > 
> > I have following behaviour now and wonder if this is expected:
> > 1. Unplug HDMI
> > 2. Run demo program
> > 3. Plugin HDMI
> > 
> > As long as the program is running, the screen will not get active.
> > When I close the program (which will release the handle to /dev/dri/card0)
> > the screen will become active.
> > 
> > Can anyone confirm that this is how it should be?
> 
> I think this is expected behavior, as you get DRM resources and not
> releasing them. Those get released automatically once you the process
> terminates then.
> 
> If you want to have your screen active, when that program is still running
> you need to call drmModeFreeResources before the while cycle.

Thank you Stan.
No issues with drmtip. The above behavior with drmtip is expected. Closing this bug as WORKSFORME.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.