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.
Created attachment 142106 [details] Test Application Source
Stan, any comments here?
(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.
(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.
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.
(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.
(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.
Wolfgang, can you address Ville's comment 7.
(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.
Reporter, any results from latest drmtip?
Not yet, I'll most likely be able to update my kernel this week.
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?
Stan, Can you confirm if the behavior is correct. If so, we can close this bug?
(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.
(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.