Force monitor detection, low level

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite
1












My external monitor (dell) is not detected on my Asus Laptop if I switch it on only after I booted the laptop.



The case similar to How to make linux detect/re-probe monitors with intel i915 driver?, except that in my case, once it is known to the laptop, I can unplug and plug it in again and get it detected.



Only when the external monitor is off during boot, I cannot get detected.



The solution with echo detect > /sys/class/drm/card0-DP-1/status, does not work, because the relevant directory would be card0-DP-2, which simply does not exist after booting while the monitor is off.



Other solutions like CTRL-ALT-F1 and back similarly don't work.



Unplugging the cable and plugging in again has no effect either. It feels a bit as if the whole displayport plug of the laptop is simply off completely.



Strange finding: if the displayport cable is not connected during boot, then the monitor is detected when I switch it on and connect the cable after booting (:-( So it seems the combination "cable connected/monitor off during boot" is interpreted as "don't bother with this hardware anymore".



Is there some command telling the system to reconsider the question whether something is connected to the display port?










share|improve this question



















  • 1




    That sounds like a possible hardware/firmware interaction issue: in the "cable connected/monitor off during boot" situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks "looks like these GPU pins are wired straight to ground, so this interface is not present". The driver won't re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help?
    – telcoM
    Aug 19 at 11:02














up vote
2
down vote

favorite
1












My external monitor (dell) is not detected on my Asus Laptop if I switch it on only after I booted the laptop.



The case similar to How to make linux detect/re-probe monitors with intel i915 driver?, except that in my case, once it is known to the laptop, I can unplug and plug it in again and get it detected.



Only when the external monitor is off during boot, I cannot get detected.



The solution with echo detect > /sys/class/drm/card0-DP-1/status, does not work, because the relevant directory would be card0-DP-2, which simply does not exist after booting while the monitor is off.



Other solutions like CTRL-ALT-F1 and back similarly don't work.



Unplugging the cable and plugging in again has no effect either. It feels a bit as if the whole displayport plug of the laptop is simply off completely.



Strange finding: if the displayport cable is not connected during boot, then the monitor is detected when I switch it on and connect the cable after booting (:-( So it seems the combination "cable connected/monitor off during boot" is interpreted as "don't bother with this hardware anymore".



Is there some command telling the system to reconsider the question whether something is connected to the display port?










share|improve this question



















  • 1




    That sounds like a possible hardware/firmware interaction issue: in the "cable connected/monitor off during boot" situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks "looks like these GPU pins are wired straight to ground, so this interface is not present". The driver won't re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help?
    – telcoM
    Aug 19 at 11:02












up vote
2
down vote

favorite
1









up vote
2
down vote

favorite
1






1





My external monitor (dell) is not detected on my Asus Laptop if I switch it on only after I booted the laptop.



The case similar to How to make linux detect/re-probe monitors with intel i915 driver?, except that in my case, once it is known to the laptop, I can unplug and plug it in again and get it detected.



Only when the external monitor is off during boot, I cannot get detected.



The solution with echo detect > /sys/class/drm/card0-DP-1/status, does not work, because the relevant directory would be card0-DP-2, which simply does not exist after booting while the monitor is off.



Other solutions like CTRL-ALT-F1 and back similarly don't work.



Unplugging the cable and plugging in again has no effect either. It feels a bit as if the whole displayport plug of the laptop is simply off completely.



Strange finding: if the displayport cable is not connected during boot, then the monitor is detected when I switch it on and connect the cable after booting (:-( So it seems the combination "cable connected/monitor off during boot" is interpreted as "don't bother with this hardware anymore".



Is there some command telling the system to reconsider the question whether something is connected to the display port?










share|improve this question















My external monitor (dell) is not detected on my Asus Laptop if I switch it on only after I booted the laptop.



The case similar to How to make linux detect/re-probe monitors with intel i915 driver?, except that in my case, once it is known to the laptop, I can unplug and plug it in again and get it detected.



Only when the external monitor is off during boot, I cannot get detected.



The solution with echo detect > /sys/class/drm/card0-DP-1/status, does not work, because the relevant directory would be card0-DP-2, which simply does not exist after booting while the monitor is off.



Other solutions like CTRL-ALT-F1 and back similarly don't work.



Unplugging the cable and plugging in again has no effect either. It feels a bit as if the whole displayport plug of the laptop is simply off completely.



Strange finding: if the displayport cable is not connected during boot, then the monitor is detected when I switch it on and connect the cable after booting (:-( So it seems the combination "cable connected/monitor off during boot" is interpreted as "don't bother with this hardware anymore".



Is there some command telling the system to reconsider the question whether something is connected to the display port?







linux-mint display monitors






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 19 at 10:17

























asked Aug 19 at 9:57









Harald

293111




293111







  • 1




    That sounds like a possible hardware/firmware interaction issue: in the "cable connected/monitor off during boot" situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks "looks like these GPU pins are wired straight to ground, so this interface is not present". The driver won't re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help?
    – telcoM
    Aug 19 at 11:02












  • 1




    That sounds like a possible hardware/firmware interaction issue: in the "cable connected/monitor off during boot" situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks "looks like these GPU pins are wired straight to ground, so this interface is not present". The driver won't re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help?
    – telcoM
    Aug 19 at 11:02







1




1




That sounds like a possible hardware/firmware interaction issue: in the "cable connected/monitor off during boot" situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks "looks like these GPU pins are wired straight to ground, so this interface is not present". The driver won't re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help?
– telcoM
Aug 19 at 11:02




That sounds like a possible hardware/firmware interaction issue: in the "cable connected/monitor off during boot" situation, the firmware probes the hardware to find out which interfaces are actually present. The monitor has some signals e.g. grounded when monitor is off, and the firmware firmware sees that and thinks "looks like these GPU pins are wired straight to ground, so this interface is not present". The driver won't re-detect the actual connectors because it assumes the firmware has supplied correct information. Perhaps a firmware upgrade could help?
– telcoM
Aug 19 at 11:02










2 Answers
2






active

oldest

votes

















up vote
2
down vote



+25










This doesn't quite answer your question per se, but is arguably a technically correct answer, so I'm taking advantage of the nicer formatting afforded to answers so this isn't 30 wall-of-text comments.



You aren't likely to get an answer on SO/SE, because there simply isn't enough domain-specific knowledge present. You're far better off talking straight to the i915 kernel driver developers.



https://01.org/linuxgraphics/documentation/how-report-bugs contains very comprehensive instructions on how to do so in an organized way.



The way you've worded your bugreport implies that /sys/class/drm/card0-DP-2/status does exist when you connect a DisplayPort cable after boot, but doesn't when a cable and no screen is connected. Well, anything involving /sys/* is definitely not X11-related, and the drm in the path absolutely confirms that you want to follow the 1.1 - DRM Kernel section from the above link.



I've had a look at the details requested by that section and am reasonably confident that the impossible-to-understand bits are not actually needed. This being said, kernel and distro info, full dmesg after rebooting with drm.debug=0xe, etc are all very good ideas.



As is somewhat obvious, two dmesgs would logically be appropriate here; one from a boot without the connector present, and another with. It may be very useful to annotate the exact or approximate point you actually plug the connector in.



5 minutes' thought came up with a suitably hacky-but-successful way to easily annotate:



script -c 'dmesg -w | cat' dmesg.txt


will run dmesg -w and also allow you to type lines of text directly into the terminal to add annotations, and you can ^C when you're done collecting dmesg info. (dmesg -w | cat is shorter than dmesg -w --color=never.)



One possibly-unlikely thing, just in case: has this ever worked? If yes, do you remember what time? If yes, try installing old versions of the distributions you used at those points, and if they work, collect the kernel versions!



Also... you may not want to hear this, but as always one cannot be 100% sure if begrudgingly getting the latest kernel version working doesn't magically fix everything. :)



Thankfully, this is much less fearful than you might fear: https://cgit.freedesktop.org/drm-tip/ is an entire clone of the Linux kernel with the drm tip-of-tree patches already folded in. As best as I can tell, just clone and build this and you should be ready to go.



...That being said, as a matter of cautiousness, you may want to download the latest kernel release and get that known-working first, and then copy the .config over to the drm-tip tree. If you don't do this first, and everything explodes sideways, verifying you can build and boot a mainline kernel may be a good first fire-squashing sanity-check.



Here's the bugzilla page you'll want: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI



Actually, that will almost certainly show you a login view; in that case you'll want this URL first: https://bugs.freedesktop.org/createaccount.cgi



Finally, if you want to ask questions, https://01.org/linuxgraphics/community/kernel mentions #gfx-intel on freenode.



FWIW, what I've described above is an ideal set of steps. You might open a provisional bug on freedesktop.org before eg going and doing a kernel rebuild to find out if there aren't some other debugging steps you can try. (The bug entry page only lists "drm git" in the version section, though, so they really want you using the git version... heh)



I actually do have a good question for the IRC channel - I listed the drm-tip git repo because that's the one the documentation mentions, but there's also an drm-intel repo, and I don't know what its relevance is. It also looks like a kernel tree, and is being updated every few minutes too.






share|improve this answer


















  • 1




    Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
    – Harald
    Sep 6 at 18:25










  • Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
    – i336_
    Sep 7 at 8:47










  • But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
    – i336_
    Sep 7 at 8:49

















up vote
0
down vote













This isn't a solution but a possible workaround:



$ env DISPLAY=:0 xset dpms force off
$ env DISPLAY=:0 xset dpms force on


The above method is from this AU Q&A titled: DisplayPort monitor not detected if switched off and on again had other solutions to a similar problem as well.



This U&L Q&A titled: How can I detect when a monitor is plugged in or unplugged? had a polling method that may help here as well.






share|improve this answer




















  • No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
    – Harald
    Aug 19 at 19:30










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f463465%2fforce-monitor-detection-low-level%23new-answer', 'question_page');

);

Post as a guest






























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



+25










This doesn't quite answer your question per se, but is arguably a technically correct answer, so I'm taking advantage of the nicer formatting afforded to answers so this isn't 30 wall-of-text comments.



You aren't likely to get an answer on SO/SE, because there simply isn't enough domain-specific knowledge present. You're far better off talking straight to the i915 kernel driver developers.



https://01.org/linuxgraphics/documentation/how-report-bugs contains very comprehensive instructions on how to do so in an organized way.



The way you've worded your bugreport implies that /sys/class/drm/card0-DP-2/status does exist when you connect a DisplayPort cable after boot, but doesn't when a cable and no screen is connected. Well, anything involving /sys/* is definitely not X11-related, and the drm in the path absolutely confirms that you want to follow the 1.1 - DRM Kernel section from the above link.



I've had a look at the details requested by that section and am reasonably confident that the impossible-to-understand bits are not actually needed. This being said, kernel and distro info, full dmesg after rebooting with drm.debug=0xe, etc are all very good ideas.



As is somewhat obvious, two dmesgs would logically be appropriate here; one from a boot without the connector present, and another with. It may be very useful to annotate the exact or approximate point you actually plug the connector in.



5 minutes' thought came up with a suitably hacky-but-successful way to easily annotate:



script -c 'dmesg -w | cat' dmesg.txt


will run dmesg -w and also allow you to type lines of text directly into the terminal to add annotations, and you can ^C when you're done collecting dmesg info. (dmesg -w | cat is shorter than dmesg -w --color=never.)



One possibly-unlikely thing, just in case: has this ever worked? If yes, do you remember what time? If yes, try installing old versions of the distributions you used at those points, and if they work, collect the kernel versions!



Also... you may not want to hear this, but as always one cannot be 100% sure if begrudgingly getting the latest kernel version working doesn't magically fix everything. :)



Thankfully, this is much less fearful than you might fear: https://cgit.freedesktop.org/drm-tip/ is an entire clone of the Linux kernel with the drm tip-of-tree patches already folded in. As best as I can tell, just clone and build this and you should be ready to go.



...That being said, as a matter of cautiousness, you may want to download the latest kernel release and get that known-working first, and then copy the .config over to the drm-tip tree. If you don't do this first, and everything explodes sideways, verifying you can build and boot a mainline kernel may be a good first fire-squashing sanity-check.



Here's the bugzilla page you'll want: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI



Actually, that will almost certainly show you a login view; in that case you'll want this URL first: https://bugs.freedesktop.org/createaccount.cgi



Finally, if you want to ask questions, https://01.org/linuxgraphics/community/kernel mentions #gfx-intel on freenode.



FWIW, what I've described above is an ideal set of steps. You might open a provisional bug on freedesktop.org before eg going and doing a kernel rebuild to find out if there aren't some other debugging steps you can try. (The bug entry page only lists "drm git" in the version section, though, so they really want you using the git version... heh)



I actually do have a good question for the IRC channel - I listed the drm-tip git repo because that's the one the documentation mentions, but there's also an drm-intel repo, and I don't know what its relevance is. It also looks like a kernel tree, and is being updated every few minutes too.






share|improve this answer


















  • 1




    Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
    – Harald
    Sep 6 at 18:25










  • Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
    – i336_
    Sep 7 at 8:47










  • But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
    – i336_
    Sep 7 at 8:49














up vote
2
down vote



+25










This doesn't quite answer your question per se, but is arguably a technically correct answer, so I'm taking advantage of the nicer formatting afforded to answers so this isn't 30 wall-of-text comments.



You aren't likely to get an answer on SO/SE, because there simply isn't enough domain-specific knowledge present. You're far better off talking straight to the i915 kernel driver developers.



https://01.org/linuxgraphics/documentation/how-report-bugs contains very comprehensive instructions on how to do so in an organized way.



The way you've worded your bugreport implies that /sys/class/drm/card0-DP-2/status does exist when you connect a DisplayPort cable after boot, but doesn't when a cable and no screen is connected. Well, anything involving /sys/* is definitely not X11-related, and the drm in the path absolutely confirms that you want to follow the 1.1 - DRM Kernel section from the above link.



I've had a look at the details requested by that section and am reasonably confident that the impossible-to-understand bits are not actually needed. This being said, kernel and distro info, full dmesg after rebooting with drm.debug=0xe, etc are all very good ideas.



As is somewhat obvious, two dmesgs would logically be appropriate here; one from a boot without the connector present, and another with. It may be very useful to annotate the exact or approximate point you actually plug the connector in.



5 minutes' thought came up with a suitably hacky-but-successful way to easily annotate:



script -c 'dmesg -w | cat' dmesg.txt


will run dmesg -w and also allow you to type lines of text directly into the terminal to add annotations, and you can ^C when you're done collecting dmesg info. (dmesg -w | cat is shorter than dmesg -w --color=never.)



One possibly-unlikely thing, just in case: has this ever worked? If yes, do you remember what time? If yes, try installing old versions of the distributions you used at those points, and if they work, collect the kernel versions!



Also... you may not want to hear this, but as always one cannot be 100% sure if begrudgingly getting the latest kernel version working doesn't magically fix everything. :)



Thankfully, this is much less fearful than you might fear: https://cgit.freedesktop.org/drm-tip/ is an entire clone of the Linux kernel with the drm tip-of-tree patches already folded in. As best as I can tell, just clone and build this and you should be ready to go.



...That being said, as a matter of cautiousness, you may want to download the latest kernel release and get that known-working first, and then copy the .config over to the drm-tip tree. If you don't do this first, and everything explodes sideways, verifying you can build and boot a mainline kernel may be a good first fire-squashing sanity-check.



Here's the bugzilla page you'll want: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI



Actually, that will almost certainly show you a login view; in that case you'll want this URL first: https://bugs.freedesktop.org/createaccount.cgi



Finally, if you want to ask questions, https://01.org/linuxgraphics/community/kernel mentions #gfx-intel on freenode.



FWIW, what I've described above is an ideal set of steps. You might open a provisional bug on freedesktop.org before eg going and doing a kernel rebuild to find out if there aren't some other debugging steps you can try. (The bug entry page only lists "drm git" in the version section, though, so they really want you using the git version... heh)



I actually do have a good question for the IRC channel - I listed the drm-tip git repo because that's the one the documentation mentions, but there's also an drm-intel repo, and I don't know what its relevance is. It also looks like a kernel tree, and is being updated every few minutes too.






share|improve this answer


















  • 1




    Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
    – Harald
    Sep 6 at 18:25










  • Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
    – i336_
    Sep 7 at 8:47










  • But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
    – i336_
    Sep 7 at 8:49












up vote
2
down vote



+25







up vote
2
down vote



+25




+25




This doesn't quite answer your question per se, but is arguably a technically correct answer, so I'm taking advantage of the nicer formatting afforded to answers so this isn't 30 wall-of-text comments.



You aren't likely to get an answer on SO/SE, because there simply isn't enough domain-specific knowledge present. You're far better off talking straight to the i915 kernel driver developers.



https://01.org/linuxgraphics/documentation/how-report-bugs contains very comprehensive instructions on how to do so in an organized way.



The way you've worded your bugreport implies that /sys/class/drm/card0-DP-2/status does exist when you connect a DisplayPort cable after boot, but doesn't when a cable and no screen is connected. Well, anything involving /sys/* is definitely not X11-related, and the drm in the path absolutely confirms that you want to follow the 1.1 - DRM Kernel section from the above link.



I've had a look at the details requested by that section and am reasonably confident that the impossible-to-understand bits are not actually needed. This being said, kernel and distro info, full dmesg after rebooting with drm.debug=0xe, etc are all very good ideas.



As is somewhat obvious, two dmesgs would logically be appropriate here; one from a boot without the connector present, and another with. It may be very useful to annotate the exact or approximate point you actually plug the connector in.



5 minutes' thought came up with a suitably hacky-but-successful way to easily annotate:



script -c 'dmesg -w | cat' dmesg.txt


will run dmesg -w and also allow you to type lines of text directly into the terminal to add annotations, and you can ^C when you're done collecting dmesg info. (dmesg -w | cat is shorter than dmesg -w --color=never.)



One possibly-unlikely thing, just in case: has this ever worked? If yes, do you remember what time? If yes, try installing old versions of the distributions you used at those points, and if they work, collect the kernel versions!



Also... you may not want to hear this, but as always one cannot be 100% sure if begrudgingly getting the latest kernel version working doesn't magically fix everything. :)



Thankfully, this is much less fearful than you might fear: https://cgit.freedesktop.org/drm-tip/ is an entire clone of the Linux kernel with the drm tip-of-tree patches already folded in. As best as I can tell, just clone and build this and you should be ready to go.



...That being said, as a matter of cautiousness, you may want to download the latest kernel release and get that known-working first, and then copy the .config over to the drm-tip tree. If you don't do this first, and everything explodes sideways, verifying you can build and boot a mainline kernel may be a good first fire-squashing sanity-check.



Here's the bugzilla page you'll want: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI



Actually, that will almost certainly show you a login view; in that case you'll want this URL first: https://bugs.freedesktop.org/createaccount.cgi



Finally, if you want to ask questions, https://01.org/linuxgraphics/community/kernel mentions #gfx-intel on freenode.



FWIW, what I've described above is an ideal set of steps. You might open a provisional bug on freedesktop.org before eg going and doing a kernel rebuild to find out if there aren't some other debugging steps you can try. (The bug entry page only lists "drm git" in the version section, though, so they really want you using the git version... heh)



I actually do have a good question for the IRC channel - I listed the drm-tip git repo because that's the one the documentation mentions, but there's also an drm-intel repo, and I don't know what its relevance is. It also looks like a kernel tree, and is being updated every few minutes too.






share|improve this answer














This doesn't quite answer your question per se, but is arguably a technically correct answer, so I'm taking advantage of the nicer formatting afforded to answers so this isn't 30 wall-of-text comments.



You aren't likely to get an answer on SO/SE, because there simply isn't enough domain-specific knowledge present. You're far better off talking straight to the i915 kernel driver developers.



https://01.org/linuxgraphics/documentation/how-report-bugs contains very comprehensive instructions on how to do so in an organized way.



The way you've worded your bugreport implies that /sys/class/drm/card0-DP-2/status does exist when you connect a DisplayPort cable after boot, but doesn't when a cable and no screen is connected. Well, anything involving /sys/* is definitely not X11-related, and the drm in the path absolutely confirms that you want to follow the 1.1 - DRM Kernel section from the above link.



I've had a look at the details requested by that section and am reasonably confident that the impossible-to-understand bits are not actually needed. This being said, kernel and distro info, full dmesg after rebooting with drm.debug=0xe, etc are all very good ideas.



As is somewhat obvious, two dmesgs would logically be appropriate here; one from a boot without the connector present, and another with. It may be very useful to annotate the exact or approximate point you actually plug the connector in.



5 minutes' thought came up with a suitably hacky-but-successful way to easily annotate:



script -c 'dmesg -w | cat' dmesg.txt


will run dmesg -w and also allow you to type lines of text directly into the terminal to add annotations, and you can ^C when you're done collecting dmesg info. (dmesg -w | cat is shorter than dmesg -w --color=never.)



One possibly-unlikely thing, just in case: has this ever worked? If yes, do you remember what time? If yes, try installing old versions of the distributions you used at those points, and if they work, collect the kernel versions!



Also... you may not want to hear this, but as always one cannot be 100% sure if begrudgingly getting the latest kernel version working doesn't magically fix everything. :)



Thankfully, this is much less fearful than you might fear: https://cgit.freedesktop.org/drm-tip/ is an entire clone of the Linux kernel with the drm tip-of-tree patches already folded in. As best as I can tell, just clone and build this and you should be ready to go.



...That being said, as a matter of cautiousness, you may want to download the latest kernel release and get that known-working first, and then copy the .config over to the drm-tip tree. If you don't do this first, and everything explodes sideways, verifying you can build and boot a mainline kernel may be a good first fire-squashing sanity-check.



Here's the bugzilla page you'll want: https://bugs.freedesktop.org/enter_bug.cgi?product=DRI



Actually, that will almost certainly show you a login view; in that case you'll want this URL first: https://bugs.freedesktop.org/createaccount.cgi



Finally, if you want to ask questions, https://01.org/linuxgraphics/community/kernel mentions #gfx-intel on freenode.



FWIW, what I've described above is an ideal set of steps. You might open a provisional bug on freedesktop.org before eg going and doing a kernel rebuild to find out if there aren't some other debugging steps you can try. (The bug entry page only lists "drm git" in the version section, though, so they really want you using the git version... heh)



I actually do have a good question for the IRC channel - I listed the drm-tip git repo because that's the one the documentation mentions, but there's also an drm-intel repo, and I don't know what its relevance is. It also looks like a kernel tree, and is being updated every few minutes too.







share|improve this answer














share|improve this answer



share|improve this answer








edited Sep 4 at 14:37

























answered Sep 4 at 14:31









i336_

315315




315315







  • 1




    Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
    – Harald
    Sep 6 at 18:25










  • Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
    – i336_
    Sep 7 at 8:47










  • But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
    – i336_
    Sep 7 at 8:49












  • 1




    Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
    – Harald
    Sep 6 at 18:25










  • Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
    – i336_
    Sep 7 at 8:47










  • But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
    – i336_
    Sep 7 at 8:49







1




1




Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
– Harald
Sep 6 at 18:25




Most likely closest to an answer as I can get. Lets see if I find the stamina to go through the process you describe. Last time I cared to compile my custom kernels was around 1998 maybe.:-)
– Harald
Sep 6 at 18:25












Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
– i336_
Sep 7 at 8:47




Ah, right. Well, the easiest way to get started then would be cat /proc/config.gz | gunzip > .config inside the root directory of the kernel tree; /proc/config.gz, if it exists (it usually does) is whatever config your current kernel is running, and should work as a good way to get going without too much thinking (although it will build modules you don't need).
– i336_
Sep 7 at 8:47












But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
– i336_
Sep 7 at 8:49




But in terms of "how do I figure out what I absolutely do need to do", I would start with IRC/Slack/the mailinglists. Who knows, they might know of a few shortcuts, or some debug info you can easily collect.
– i336_
Sep 7 at 8:49












up vote
0
down vote













This isn't a solution but a possible workaround:



$ env DISPLAY=:0 xset dpms force off
$ env DISPLAY=:0 xset dpms force on


The above method is from this AU Q&A titled: DisplayPort monitor not detected if switched off and on again had other solutions to a similar problem as well.



This U&L Q&A titled: How can I detect when a monitor is plugged in or unplugged? had a polling method that may help here as well.






share|improve this answer




















  • No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
    – Harald
    Aug 19 at 19:30














up vote
0
down vote













This isn't a solution but a possible workaround:



$ env DISPLAY=:0 xset dpms force off
$ env DISPLAY=:0 xset dpms force on


The above method is from this AU Q&A titled: DisplayPort monitor not detected if switched off and on again had other solutions to a similar problem as well.



This U&L Q&A titled: How can I detect when a monitor is plugged in or unplugged? had a polling method that may help here as well.






share|improve this answer




















  • No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
    – Harald
    Aug 19 at 19:30












up vote
0
down vote










up vote
0
down vote









This isn't a solution but a possible workaround:



$ env DISPLAY=:0 xset dpms force off
$ env DISPLAY=:0 xset dpms force on


The above method is from this AU Q&A titled: DisplayPort monitor not detected if switched off and on again had other solutions to a similar problem as well.



This U&L Q&A titled: How can I detect when a monitor is plugged in or unplugged? had a polling method that may help here as well.






share|improve this answer












This isn't a solution but a possible workaround:



$ env DISPLAY=:0 xset dpms force off
$ env DISPLAY=:0 xset dpms force on


The above method is from this AU Q&A titled: DisplayPort monitor not detected if switched off and on again had other solutions to a similar problem as well.



This U&L Q&A titled: How can I detect when a monitor is plugged in or unplugged? had a polling method that may help here as well.







share|improve this answer












share|improve this answer



share|improve this answer










answered Aug 19 at 19:09









slm♦

238k65493664




238k65493664











  • No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
    – Harald
    Aug 19 at 19:30
















  • No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
    – Harald
    Aug 19 at 19:30















No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
– Harald
Aug 19 at 19:30




No luck. The laptop screen flashes, but the additional monitor stays off and no DP-2 in /sys/class/drm.:-(
– Harald
Aug 19 at 19:30

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f463465%2fforce-monitor-detection-low-level%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?