Thread: [Unichrome] (EE) VIA(0): No outputs possible.
Brought to you by:
dwdeath
From: Barry S. <bar...@on...> - 2006-08-08 10:05:37
|
Luc, I see this message if I bring up X with the VGA cable unplugged. (EE) VIA(0): No outputs possible. Since the driver does not need to query DDC or EDID with my configuration I'm wondering why the driver is unwilling to setup the display with the cable unplugged. I'm not sure but I think the driver used to work with the cable unplugged when X started up. Is this a change in behavior or something that I have only just noticed? Is there way to config the driver to keep going in this situation? Barry |
From: Luc V. <li...@sk...> - 2006-08-08 11:36:41
|
On Tue, Aug 08, 2006 at 11:05:32AM +0100, Barry Scott wrote: > Luc, > > I see this message if I bring up X with the VGA cable unplugged. > > (EE) VIA(0): No outputs possible. > > Since the driver does not need to query DDC or EDID with my configuration > I'm wondering why the driver is unwilling to setup the display with the > cable > unplugged. > > I'm not sure but I think the driver used to work with the cable > unplugged when > X started up. Is this a change in behavior or something that I have only > just noticed? > > Is there way to config the driver to keep going in this situation? > > Barry Yes, since the driver can't detect the CRT, since there's nothing connected to the TV encoder, and it doesn't know about any panels, it decides that it's no use starting. Without dynamic (re)configuration, when the output layout is decided at PreInit, this is the sanest solution. In case of the NTB though, it is disruptive. You need to tell it Option "ActiveDevice" "CRT" if you want it to always use the CRT. Luc Verhaegen. |
From: Barry S. <bar...@on...> - 2006-08-08 12:07:39
|
Luc Verhaegen wrote: > Yes, since the driver can't detect the CRT, since there's nothing > connected to the TV encoder, and it doesn't know about any panels, it > decides that it's no use starting. > This is not a reasonable thing to do in our situation. We often power up a set of machines to burn them in with on display connected. > Without dynamic (re)configuration, when the output layout is decided at > PreInit, this is the sanest solution. In case of the NTB though, it is > disruptive. > > You need to tell it Option "ActiveDevice" "CRT" if you want it to always > use the CRT. > If I do this does it stop the auto detect of the Composite and S-Video outputs? > Luc Verhaegen. > Barry |
From: Barry S. <bar...@on...> - 2006-08-10 13:04:25
|
Luc Verhaegen. wrote: > Yeah, in the end it does the same thing, it just doesn't have the driver > default to CRT at _all_ times. For instance, a CRT without EDID and > without config, is a sad affair because i'm forced to use antique 14" > fishbowls that predate multisync as the absolute baseline CRT. > The reason I turn off DDC/EDID is so that my users get the screen resolution that matches the media they have designed. For example an NEC plasma will report 1024x768 via EDID buts its wide screen so people design in 1280x768 and let the plasma scale. >> I will need a way to turn off dynamic configuration when you get this >> feature implemented. >> >> Barry >> > > Maybe not turn off entirely. The hope is that default behaviour will be > sane enough at that point. X could just hang around until it does find > an output, then it should pop up magically. It's mainly the > halfarsedness of current X modesetting that's causing problems here, and > the still early stage of useful modesetting in my driver. > > But yeah, i fully understand that you can't leave your customers at the > console. Dynamic modesetting means attribute system and that means new X > extension. Your onelan deamons can then control most aspects of > modesetting directly. You will be able to tell the driver to probe all > outputs and choose which, when available, will be used. > What I really want is to have my daemon be in the loop as a policy object. I want to be given the data on the outputs and screens and then to apply my policy to choose what is used and how it is used. What I plan to do in the short term is run up X once allowing DDC/EDID to be probed and reported in the X log file. Then kill off X and start up again having applied a policy to the DDC/EDID info. BTW do you know of any standalone program that can do the DDC/EDID query without running up X? > That's where i'm generally headed, but progress could be faster, of > course. > Understood. Barry |
From: Luc Verhaegen. <li...@sk...> - 2006-08-11 15:07:50
|
On Thu, Aug 10, 2006 at 02:04:19PM +0100, Barry Scott wrote: > The reason I turn off DDC/EDID is so that my users get the screen resolution > that matches the media they have designed. For example an NEC plasma will > report 1024x768 via EDID buts its wide screen so people design in 1280x768 > and let the plasma scale. So it never mentions 1280x768 in the EDID, but it does downscale itself? I think at some future point in X modesetting that might cause problems requiring special workarounds. > What I really want is to have my daemon be in the loop as a policy object. > I want to be given the data on the outputs and screens and then to apply my > policy to choose what is used and how it is used. Yup, we're definitely on the same page here. The most direct use of an attribute system would be a hardware specific gui which exposes the most minute details. Then there should be an X utility for the general stuff, then gnome and kde config supporting the general stuff. There should be nothing stopping other applications (except security) from controlling what's happening with regard to modesetting. My (relatively) short term intention is to release a console client which exposes the full structure of unichrome modesetting. It will not be intuitive to use for the novice (well, my guess is that i'll be the only person who knows his way around it initially), but it will allow complete and full control solely depending on what the driver exposes (which is why it'll not be too intuitive). The big problem is the still unresolved issues with CLE266 based panel and the CH7019 LVDS encoder on the Acer aspire 135x. They still are the nasty blind spots in my otherwise highly structured modesetting. Luckily my work on VT3108 panel has given me some insights that allowed me to strip down the panel code (dropped 200+kB - notice how compiling via_panel.o now zips by). I am very afraid though that I will have broken pre-VT3108 support, but at least now it should be easier to fix. > What I plan to do in the short term is run up X once allowing DDC/EDID to > be probed and reported in the X log file. Then kill off X and start up again > having applied a policy to the DDC/EDID info. Sounds like just as much work as doing it properly from the get-go. The most rudimentary controls can be implemented rather quickly. The real trouble here is that Keith Packard doesn't believe in a general attribute system, he prefers to continuously extend randr. I think this is due to the different angles the problem is approached. I'm a driver developer and i think from the driver up; i want to expose as much of the hardware as sanely possible. I believe Keith only wants to expose that functionality that is useful to him at a given time. For the user, in the short term, it means that you'll end up with 2 different systems for both this driver and the intel one. > BTW do you know of any standalone program that can do the DDC/EDID > query without running up X? There's that utility that uses VBE calls, read-edid, but other than that, no, not really. You need to control the I2C bus to the CRT to be able to read EDID. And that's in the X driver. Luc Verhaegen. |
From: Luc Verhaegen. <li...@sk...> - 2006-08-08 13:48:25
|
On Tue, Aug 08, 2006 at 01:07:28PM +0100, Barry Scott wrote: > Luc Verhaegen wrote: > >Yes, since the driver can't detect the CRT, since there's nothing > >connected to the TV encoder, and it doesn't know about any panels, it > >decides that it's no use starting. > > > This is not a reasonable thing to do in our situation. We often power up > a set of machines to burn them in with on display connected. Well, the hardware can tell wether or not there is a CRT attached. If it doesn't know what to activate, then returning to the VT is the best thing to do, as you might get a broken X mode, and you might leave the user with a broken console as well. It's better to return to VT right away and leave the user a way to adjust the config. > >Without dynamic (re)configuration, when the output layout is decided at > >PreInit, this is the sanest solution. In case of the NTB though, it is > >disruptive. > > > >You need to tell it Option "ActiveDevice" "CRT" if you want it to always > >use the CRT. > > > If I do this does it stop the auto detect of the Composite and S-Video > outputs? > It doesn't even try to detect the TVs DAC connections. As far as the driver is concerned, it only should care about the CRT, because it was told to only care about the CRT, even when there is no CRT. The difference between now and then is that now, it does know when or when not a CRT is attached. Such is life without dynamic configuration. Luc Verhaegen. |
From: Barry S. <bar...@on...> - 2006-08-08 16:16:49
|
Luc Verhaegen. wrote: > On Tue, Aug 08, 2006 at 01:07:28PM +0100, Barry Scott wrote: > >> Luc Verhaegen wrote: >> >>> Yes, since the driver can't detect the CRT, since there's nothing >>> connected to the TV encoder, and it doesn't know about any panels, it >>> decides that it's no use starting. >>> >>> >> This is not a reasonable thing to do in our situation. We often power up >> a set of machines to burn them in with on display connected. >> > > Well, the hardware can tell wether or not there is a CRT attached. If it > doesn't know what to activate, then returning to the VT is the best > thing to do, as you might get a broken X mode, and you might leave the > user with a broken console as well. > > > It's better to return to VT right away and leave the user a way to > adjust the config. > Not if the box is a turn key system as ours is. There isn't a user to fix things. This is a policy decision that I understand your reasoning for. But think is wrong. I think this is the only driver that works this way. For our use we will need to patch the driver to revert back to the old behavior. I'll post a patch once I have it. This has become a show stopper bug for us. Barry |
From: Barry S. <bar...@on...> - 2006-08-08 17:26:26
Attachments:
fix-no-outputs-possible.txt
|
Luc Verhaegen. wrote: > I'll introduce option "CRTSense" (Bool) which will not be listed in the > manpage. > > An other option is to restart X every given number of seconds, this > until a CRT is found. > > Some future situation will have the driver regularly probing all > outputs. > The attached patch fixes the problem (with the minimum diff, eg. no indent level changes. I'll test more tomorrow and make sure that all the auto sensing that we use for Composit and S-Video is still working. The behavior I want is: Use Composite or S-Video if output is connected else Force use of CRT. To have the driver support your policy and mine we need a bool that has the effect of switching the patch in and out an run time. I've leave plug-n-play changes in futures drivers till another day to worry about. Barry |
From: Luc Verhaegen. <li...@sk...> - 2006-08-09 22:09:21
|
On Tue, Aug 08, 2006 at 06:26:19PM +0100, Barry Scott wrote: > > The attached patch fixes the problem (with the minimum diff, eg. no > indent level changes. > I'll test more tomorrow and make sure that all the auto sensing that we > use for Composit > and S-Video is still working. > > The behavior I want is: > > Use Composite or S-Video if output is connected > else Force use of CRT. > > To have the driver support your policy and mine we need > a bool that has the effect of switching the patch in and out > an run time. > > I've leave plug-n-play changes in futures drivers till another day to > worry about. > > Barry > I've commited CRTSense Option instead. This effectively makes the driver as dumb as before i dug out the BIOS to find out about CRT Sensing. The default behaviour is TRUE, although VT3122Ax doesn't have this functionality. When set to FALSE, the Sense callback will not be attached to the CRTs output structure. When an output doesn't have the Sense function provided, the driver assumes that the output is always attached. Dynamic configuration has been a goal for ages. There will be a time where the driver will wait until an output is possible before going into ScreenInit. Luc Verhaegen. |
From: Barry S. <bar...@on...> - 2006-08-10 10:09:45
|
Luc Verhaegen. wrote: > On Tue, Aug 08, 2006 at 06:26:19PM +0100, Barry Scott wrote: > >> The attached patch fixes the problem (with the minimum diff, eg. no >> indent level changes. >> I'll test more tomorrow and make sure that all the auto sensing that we >> use for Composit >> and S-Video is still working. >> >> The behavior I want is: >> >> Use Composite or S-Video if output is connected >> else Force use of CRT. >> >> To have the driver support your policy and mine we need >> a bool that has the effect of switching the patch in and out >> an run time. >> >> I've leave plug-n-play changes in futures drivers till another day to >> worry about. >> >> Barry >> >> > I've commited CRTSense Option instead. This effectively makes the driver > as dumb as before i dug out the BIOS to find out about CRT Sensing. > > The default behaviour is TRUE, although VT3122Ax doesn't have this > functionality. When set to FALSE, the Sense callback will not be > attached to the CRTs output structure. When an output doesn't have the > Sense function provided, the driver assumes that the output is always > attached. > I'll test this and report back. I think this does what I want. > Dynamic configuration has been a goal for ages. There will be a time > where the driver will wait until an output is possible before going > into ScreenInit. > I will need a way to turn off dynamic configuration when you get this feature implemented. Barry |
From: Luc Verhaegen. <li...@sk...> - 2006-08-10 12:16:58
|
On Thu, Aug 10, 2006 at 11:09:31AM +0100, Barry Scott wrote: > Luc Verhaegen. wrote: > >On Tue, Aug 08, 2006 at 06:26:19PM +0100, Barry Scott wrote: > > > >I've commited CRTSense Option instead. This effectively makes the driver > >as dumb as before i dug out the BIOS to find out about CRT Sensing. > > > >The default behaviour is TRUE, although VT3122Ax doesn't have this > >functionality. When set to FALSE, the Sense callback will not be > >attached to the CRTs output structure. When an output doesn't have the > >Sense function provided, the driver assumes that the output is always > >attached. > > > I'll test this and report back. I think this does what I want. > Yeah, in the end it does the same thing, it just doesn't have the driver default to CRT at _all_ times. For instance, a CRT without EDID and without config, is a sad affair because i'm forced to use antique 14" fishbowls that predate multisync as the absolute baseline CRT. > I will need a way to turn off dynamic configuration when you get this > feature implemented. > > Barry Maybe not turn off entirely. The hope is that default behaviour will be sane enough at that point. X could just hang around until it does find an output, then it should pop up magically. It's mainly the halfarsedness of current X modesetting that's causing problems here, and the still early stage of useful modesetting in my driver. But yeah, i fully understand that you can't leave your customers at the console. Dynamic modesetting means attribute system and that means new X extension. Your onelan deamons can then control most aspects of modesetting directly. You will be able to tell the driver to probe all outputs and choose which, when available, will be used. That's where i'm generally headed, but progress could be faster, of course. Luc Verhaegen. |
From: Luc Verhaegen. <li...@sk...> - 2006-08-08 17:13:06
|
On Tue, Aug 08, 2006 at 05:16:45PM +0100, Barry Scott wrote: > > Not if the box is a turn key system as ours is. There isn't a user to > fix things. > This is a policy decision that I understand your reasoning for. But > think is wrong. I think this is the only driver that works this way. > > For our use we will need to patch the driver to revert back to the old > behavior. > I'll post a patch once I have it. This has become a show stopper bug for us. > > Barry > I'll introduce option "CRTSense" (Bool) which will not be listed in the manpage. An other option is to restart X every given number of seconds, this until a CRT is found. Some future situation will have the driver regularly probing all outputs. Luc Verhaegen. |