Luc Verhaegen writes:
This is some issue with my edid handling. As far as i can tell, no mode has been created for the detailed timing mode there, i can't tell why yet.
I hope i can look into this in the evening.
This is an issue of old code. SELD10 still uses R6.9 which doesn't have your fixes for the EDID code. Cheers, Egbert. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Oct 09, 2007 at 08:17:12AM +0200, Egbert Eich wrote:
Luc Verhaegen writes:
This is some issue with my edid handling. As far as i can tell, no mode has been created for the detailed timing mode there, i can't tell why yet.
I hope i can look into this in the evening.
This is an issue of old code. SELD10 still uses R6.9 which doesn't have your fixes for the EDID code.
Cheers, Egbert.
Ah, right, that one. We should have a driver side workaround for this, as iirc, this issue came up quite early on. I'm left wondering why i have not seen this more on my unichrome driver, because then i would've had a workaround there already, which would've been ported to this driver as well. I've been talking to Stefan about pulling these small changes into sled. So far, he seems ok with this, i am not sure myself when this will be pushed out, probably with the next service pack. So we will still need a driver side workaround, for certain Xserver versions. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi Luc, Le mardi 9 octobre 2007 12:36, Luc Verhaegen a écrit :
On Tue, Oct 09, 2007 at 08:17:12AM +0200, Egbert Eich wrote:
This is an issue of old code. SELD10 still uses R6.9 which doesn't have your fixes for the EDID code.
Ah, right, that one.
We should have a driver side workaround for this, as iirc, this issue came up quite early on.
I agree that a workaround would be welcome. This was a showstopper for me. As I suspect that most displays need a detailed timing for proper operation, this makes the radeonhd driver seomwhat useless on SLED10 SP1 or any other distribution where X has the bug in question.
I'm left wondering why i have not seen this more on my unichrome driver, because then i would've had a workaround there already, which would've been ported to this driver as well.
This is an excellent question, I've been wondering the same, not only for the unichrome driver but for pretty much all the X drivers: if the bug has gone unnoticed for years, how have the other drivers been dealing with it? Do they check the sync flags at all? Do we really need to check them in radeonhd?
I've been talking to Stefan about pulling these small changes into sled. So far, he seems ok with this, i am not sure myself when this will be pushed out, probably with the next service pack.
Would be great, yeah.
So we will still need a driver side workaround, for certain Xserver versions.
Newbie question: how do we detect the X server version? Does it happen at build time or at runtime? The problem I see is that, if we fix the bug in SLED10 SP2, the X server version will still be 6.9. If our workaround is enabled depending on the version, we need to make sure that it's forward compatible, i.e. that it doesn't _assume_ that the X server has the bug, so that it doesn't break once the bug is fixed. And that's not only important for SLED10 SP2 - any distribution where the bug fix has been backported to X 6.9 will break if the workaround isn't forward compatible. The most simple forward compatible workaround would be to not check the sync flag at all if the X server version is < 7. A slightly more conservative one would be to accept both 1 and 3 as acceptable flag values (that's what I'm doing right now.) Thanks, -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, Oct 09, 2007 at 04:40:56PM +0200, Jean Delvare wrote:
Hi Luc,
Le mardi 9 octobre 2007 12:36, Luc Verhaegen a ?crit?:
On Tue, Oct 09, 2007 at 08:17:12AM +0200, Egbert Eich wrote:
This is an issue of old code. SELD10 still uses R6.9 which doesn't have your fixes for the EDID code.
Ah, right, that one.
We should have a driver side workaround for this, as iirc, this issue came up quite early on.
I agree that a workaround would be welcome. This was a showstopper for me. As I suspect that most displays need a detailed timing for proper operation, this makes the radeonhd driver seomwhat useless on SLED10 SP1 or any other distribution where X has the bug in question.
This affects all drivers that try to use this EDID data. It is a server side issue, in the DDC module. Egbert wrote this code in 1999, without access to VESA standards, and the layout was not public information then either. Considering that, the fact that there just were just a few bits off is quite amazing.
I'm left wondering why i have not seen this more on my unichrome driver, because then i would've had a workaround there already, which would've been ported to this driver as well.
This is an excellent question, I've been wondering the same, not only for the unichrome driver but for pretty much all the X drivers: if the bug has gone unnoticed for years, how have the other drivers been dealing with it? Do they check the sync flags at all? Do we really need to check them in radeonhd?
I introduced EDID handling in late 2005/early 2006. This was the first time that this field in the EDID information was used, and so it was the first time that anyone discovered the bug in the edid parsing.
I've been talking to Stefan about pulling these small changes into sled. So far, he seems ok with this, i am not sure myself when this will be pushed out, probably with the next service pack.
Would be great, yeah.
So we will still need a driver side workaround, for certain Xserver versions.
Newbie question: how do we detect the X server version? Does it happen at build time or at runtime?
This would be a define, so the X server version would be checked at build time.
The problem I see is that, if we fix the bug in SLED10 SP2, the X server version will still be 6.9. If our workaround is enabled depending on the version, we need to make sure that it's forward compatible, i.e. that it doesn't _assume_ that the X server has the bug, so that it doesn't break once the bug is fixed. And that's not only important for SLED10 SP2 - any distribution where the bug fix has been backported to X 6.9 will break if the workaround isn't forward compatible.
We could also just parse this 2bit field ourselves in case of a known broken server. So we would, in our driver, ignore whatever the ddc module chose for us on affected X server versions, and as such, even on the upcoming sled one. This doesn't mean that the X side change shouldn't be pushed into sled, as other drivers (like backported randr1.2 drivers -- this also uses my edid handling code) might suddenly also become happier.
The most simple forward compatible workaround would be to not check the sync flag at all if the X server version is < 7. A slightly more conservative one would be to accept both 1 and 3 as acceptable flag values (that's what I'm doing right now.)
Don't worry, a fully working and acceptable fix will be pushed in when i have the time. Luc Verhaegen. SUSE/Novell X Driver Developer. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Hi Luc, Le mardi 9 octobre 2007 19:10, Luc Verhaegen a écrit :
On Tue, Oct 09, 2007 at 04:40:56PM +0200, Jean Delvare wrote:
The most simple forward compatible workaround would be to not check the sync flag at all if the X server version is < 7. A slightly more conservative one would be to accept both 1 and 3 as acceptable flag values (that's what I'm doing right now.)
Don't worry, a fully working and acceptable fix will be pushed in when i have the time.
Great, thanks. Let me know if I can help with the code or with testing. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (3)
-
Egbert Eich -
Jean Delvare -
Luc Verhaegen