8:23 a.m.
tor, 30 08 2007 kl. 07:36 -0400, skrev Neal Becker:
Correct me if I'm wrong but isn't this another copout solution to not
detecting resolution correct or otherwise accidently messing up the
configuration. It seems to be nothing more than a fallback in case X
doesn't do it's job then it presumes that the user actually knows what
hardware he has and what resolution is desired (if my mothers machine
did that she'd run away screaming - definitely not a solution that is
suitable for everyone).
Regardless calling it bulletproof X seems misleading. It also doesn't
really do anything to aid the situation as far as I can see either, it's
not like it opens a bug against the correct X component with all the
logs attached so a developer might have an enjoyable afternoon figuring
out what went wrong so it can be avoided in the future.
It seems to me that "bulletproof" should have meant no crashing and no
misconfigurations.. ever.
- David
8:49 a.m.
I think the main purpose is for people who are using proprietary
drivers (maily nvidia) and have kernel module breakages. Also for
those messing around with other settings manually (trying to get a
multi-button mouse working, for example). For those not used to linux
I can see how this could let them get online in order to get help.
But I also think it is poorly implemented. Why not ask the user when
they update xorg.conf if their previous one worked, and then if they
want to save it as a fall-back in case the new one fails. This way
you don't end up any worse off if it fails. You'd have to make the
name of the backup well known enough for those manually editing the
file to save the backup properly (xorg.conf.bak seems fairly standard
for this, yes?), but I feel like most users who would need this would
be using Ubuntu's GUI xorg.conf tool, and that could be built right
in.
On 8/30/07, David Nielsen <david(a)lovesunix.net> wrote:
tor, 30 08 2007 kl. 07:36 -0400, skrev Neal Becker:
>
http://arstechnica.com/journals/linux.ars/2007/08/29/ubuntu-xorg-maintain...
Correct me if I'm wrong but isn't this another copout solution to not
detecting resolution correct or otherwise accidently messing up the
configuration. It seems to be nothing more than a fallback in case X
doesn't do it's job then it presumes that the user actually knows what
hardware he has and what resolution is desired (if my mothers machine
did that she'd run away screaming - definitely not a solution that is
suitable for everyone).
Regardless calling it bulletproof X seems misleading. It also doesn't
really do anything to aid the situation as far as I can see either, it's
not like it opens a bug against the correct X component with all the
logs attached so a developer might have an enjoyable afternoon figuring
out what went wrong so it can be avoided in the future.
It seems to me that "bulletproof" should have meant no crashing and no
misconfigurations.. ever.
- David
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
3:54 a.m.
On Thu, 2007-08-30 at 13:49 +0000, igknighted(a)gmail.com wrote:
I think the main purpose is for people who are using proprietary
drivers (maily nvidia) and have kernel module breakages. Also for
those messing around with other settings manually (trying to get a
multi-button mouse working, for example). For those not used to linux
I can see how this could let them get online in order to get help.
But I also think it is poorly implemented. Why not ask the user when
they update xorg.conf if their previous one worked, and then if they
want to save it as a fall-back in case the new one fails. This way
you don't end up any worse off if it fails. You'd have to make the
name of the backup well known enough for those manually editing the
file to save the backup properly (xorg.conf.bak seems fairly standard
for this, yes?), but I feel like most users who would need this would
be using Ubuntu's GUI xorg.conf tool, and that could be built right
in.
Really if you have to ask the user you've already lost....
The main use this gives is you can let a user try the binary driver, and
if it tanks, you can use the GUI to go back to the open source or vice
versa,
Really though a simple ordering like:
1. Users current xorg.conf
2. No x.org conf - default driver
3. Try another driver in list (like fglrx or radeon)
4. Try vesa.
5. lose.
I'm not sure what asking the user in-between really gives you..
Dave.
6:14 p.m.
fre, 31 08 2007 kl. 18:54 +1000, skrev Dave Airlie:
On Thu, 2007-08-30 at 13:49 +0000, igknighted(a)gmail.com wrote:
> I think the main purpose is for people who are using proprietary
> drivers (maily nvidia) and have kernel module breakages. Also for
> those messing around with other settings manually (trying to get a
> multi-button mouse working, for example). For those not used to linux
> I can see how this could let them get online in order to get help.
>
> But I also think it is poorly implemented. Why not ask the user when
> they update xorg.conf if their previous one worked, and then if they
> want to save it as a fall-back in case the new one fails. This way
> you don't end up any worse off if it fails. You'd have to make the
> name of the backup well known enough for those manually editing the
> file to save the backup properly (xorg.conf.bak seems fairly standard
> for this, yes?), but I feel like most users who would need this would
> be using Ubuntu's GUI xorg.conf tool, and that could be built right
> in.
>
Really if you have to ask the user you've already lost....
The main use this gives is you can let a user try the binary driver, and
if it tanks, you can use the GUI to go back to the open source or vice
versa,
Really though a simple ordering like:
1. Users current xorg.conf
2. No x.org conf - default driver
3. Try another driver in list (like fglrx or radeon)
4. Try vesa.
5. lose.
I'm not sure what asking the user in-between really gives you..
Easy, top story on Digg 3 days in a row.. not that that makes it
worthwhile or even correct but that seems to be the net gain.
- David
6:27 p.m.
Dave Airlie wrote:
On Thu, 2007-08-30 at 13:49 +0000, igknighted(a)gmail.com wrote:
> I think the main purpose is for people who are using proprietary
> drivers (maily nvidia) and have kernel module breakages. Also for
> those messing around with other settings manually (trying to get a
> multi-button mouse working, for example). For those not used to linux
> I can see how this could let them get online in order to get help.
>
> But I also think it is poorly implemented. Why not ask the user when
> they update xorg.conf if their previous one worked, and then if they
> want to save it as a fall-back in case the new one fails. This way
> you don't end up any worse off if it fails. You'd have to make the
> name of the backup well known enough for those manually editing the
> file to save the backup properly (xorg.conf.bak seems fairly standard
> for this, yes?), but I feel like most users who would need this would
> be using Ubuntu's GUI xorg.conf tool, and that could be built right
> in.
>
Really if you have to ask the user you've already lost....
The main use this gives is you can let a user try the binary driver, and
if it tanks, you can use the GUI to go back to the open source or vice
versa,
Really though a simple ordering like:
1. Users current xorg.conf
2. No x.org conf - default driver
3. Try another driver in list (like fglrx or radeon)
4. Try vesa.
5. lose.
I'm not sure what asking the user in-between really gives you..
RTFA...
"
One of the most impressive new features in Ubuntu's BulletProof-X
implementation is support for reading monitor settings from a Windows
driver CD. "Unfortunately, it doesn't work to select just any of the
generic monitors, so users may find they need to trial-and-error a
solution. Fortunately, there is a cool new feature—Add Model which
allows users to add a new monitor by using the Windows driver CD that
comes with their monitor," Harrington writes. "This uses a script to
parse the Windows *.inf file to get the hsync, vsync, edid, dpms, and
other info to update the database locally."
"
-dmc
2:54 p.m.
On Thu, 2007-08-30 at 18:27 -0500, Douglas McClendon wrote:
Dave Airlie wrote:
> Really if you have to ask the user you've already lost....
>
> The main use this gives is you can let a user try the binary driver, and
> if it tanks, you can use the GUI to go back to the open source or vice
> versa,
>
> Really though a simple ordering like:
> 1. Users current xorg.conf
> 2. No x.org conf - default driver
> 3. Try another driver in list (like fglrx or radeon)
> 4. Try vesa.
> 5. lose.
>
> I'm not sure what asking the user in-between really gives you..
RTFA...
"
One of the most impressive new features in Ubuntu's BulletProof-X
implementation is support for reading monitor settings from a Windows
driver CD. "Unfortunately, it doesn't work to select just any of the
generic monitors, so users may find they need to trial-and-error a
solution. Fortunately, there is a cool new feature—Add Model which
allows users to add a new monitor by using the Windows driver CD that
comes with their monitor," Harrington writes. "This uses a script to
parse the Windows *.inf file to get the hsync, vsync, edid, dpms, and
other info to update the database locally."
"
Hilariously, they're using inf2mondb.py for this. You know, the one msw
wrote like five years ago, that's in our hwdata CVS, and that we use to
construct /usr/share/hwdata/MonitorsDB.
The whole reason we're _not_ using this very much - and that I've
effectively stopped updating MonitorsDB - is because the inf files don't
give you useful information. They give you sync ranges and that's about
it. So you end up in some pretty hilarious situations, because X
prefers width over height, so even though your monitor's 1600x1200, the
sync range is big enough to fit 1680x1050, so you'll try to fit that,
and lose.
There does happen to be a variable in inf2mondb that's named 'edid', but
it's not actually the full EDID block. It's a tuple of the EISA vendor
ID and a model number. This, it turns out, is not useful for
configuration. So while Bryce might have read the script with the best
of intentions, he clearly hasn't tried to use it in anger.
So yeah, hooray, they have a feature that doesn't work. Good for them.
Now, you can get most of the way to right by just adding maximum pixel
clock to the available configuration options in xorg.conf's Monitor
section, which fixes the width problem I mentioned above. I've (very,
very slowly) been pushing s-c-d in this direction, which is why it now
hides the big brutal list of vendor/model monitor combos and only shows
generic sizes by default, so it can (eventually) compute the sync ranges
and max pixel clock from the size and the appropriate timing formula for
the display type. It still gets some things wrong and I happily accept
patches, in particular it won't actually write out Option "MaxPixClock"
anywhere. But it's a way more correct approach than what the article
describes.
If I were being cynical, I'd say a large part of the reason they'll be
moderately successful at this whole 'bulletproof' thing is due to work
I've already put in to fixing autoconfiguration within X itself, and
that the press releases are just so much propaganda. Don't get me
wrong, Fedora sucks at self-publicity, we should do better, but all I
see in that project is prettier UI and not technical correctness. If
you do it _right_, you don't ever have to admit failure. Asking for the
inf file is admitting failure.
- ajax
4:03 p.m.
Adam Jackson wrote:
If I were being cynical, I'd say a large part of the reason
they'll be
moderately successful at this whole 'bulletproof' thing is due to work
I've already put in to fixing autoconfiguration within X itself, and
that the press releases are just so much propaganda. Don't get me
wrong, Fedora sucks at self-publicity, we should do better, but all I
see in that project is prettier UI and not technical correctness. If
you do it _right_, you don't ever have to admit failure. Asking for the
inf file is admitting failure.
I suspect you'll tell me why I'm wrong- But aren't there (a significant
number of) situations where autodetect fails, and in fact due to
hardware limitations can't succeed, but the process of the user
specifying the monitor type, and info, from the driver CD, will cause
success?
Even if those situations account for 1/10,000 users, those are precisely
the cases that need to be covered to market something as "bulletproof".
Now of course, it won't solve the problem of the user getting confused
and using the wrong CD for the monitor...
-dmc
7:24 a.m.
On 2007-09-01, 21:03 GMT, Douglas McClendon wrote:
Even if those situations account for 1/10,000 users, those are
precisely the cases that need to be covered to market something
as "bulletproof".
People who are able to find all necessary numbers will most
likely have no problem with the most mature front-end for the
X configuration -- you know, the know which name consists only
from letters "v" and "i" (in this order ;-)).
No really, what I read in Adam's email (and what's my experience
from reading hundreds of Xorg bugs, being bugmaster for RH
desktop I read a lot of them), the problems we have are not in
not having enough information about hardware (take a look at
/var/log/Xorg.0.log -- there is plenty of information there) --
it's that quite often the information provided by hardware is
plainly wrong, or that xorg drivers suck. Concerning the former,
I don't understand how would information provided to Windows by
the vendor was that much better than information they provide via
hardware. And concerning the latter, I don't see any relation to
"bulletproof X" whatsoever.
Please, correct me if I am wrong.
Matej
2:52 p.m.
Matej Cepl wrote:
On 2007-09-01, 21:03 GMT, Douglas McClendon wrote:
> Even if those situations account for 1/10,000 users, those are
> precisely the cases that need to be covered to market something
> as "bulletproof".
People who are able to find all necessary numbers will most
likely have no problem with the most mature front-end for the
X configuration -- you know, the know which name consists only
from letters "v" and "i" (in this order ;-)).
Very funny. Obviously the ubuntu tool is designed specifically for
people who are not put off by inserting a hardware vendors windows
driver cd into the cdrom, but are put off by using vi.
No really, what I read in Adam's email (and what's my experience
from reading hundreds of Xorg bugs, being bugmaster for RH
desktop I read a lot of them), the problems we have are not in
not having enough information about hardware (take a look at
/var/log/Xorg.0.log -- there is plenty of information there) --
it's that quite often the information provided by hardware is
plainly wrong, or that xorg drivers suck.
Concerning the former,
I don't understand how would information provided to Windows by
the vendor was that much better than information they provide via
hardware.
Umm... Please think about this a bit more. If the data provided by the
hardware is "plainly wrong" or "broken", then that is precisely the
time
when data provided on the winblowz driver CD might be right.
Honestly I can't vouch that this is ever the case. It is pure
speculation on my part. But I for one get sick of hearing "you're
hardware is broken, go suck an egg", when clearly that hardware is not
broken enough to not work on windows, using the mechanisms they have in
place (e.g. presumably reading the data from the driver cd).
(and again, for the sake of argument, lets pretend that doing anything
from a command line, or editing a text file, or researching obscure
specs about your monitor, is not an option for the users in question)
And concerning the latter, I don't see any relation to
"bulletproof X" whatsoever.
correct, nothing in the thread I started, has to do with xorg drivers
sucking. It only has to do with monitor configuration, when presumably
the monitor hardware is failing to provide the correct info to the xorg
driver. (though I suppose the same situation could occur if there was a
bug in the xorg driver reading the information).
But again, this is speculation on my part. Please correct me if I'm
wrong. :)
-dmc
4:41 p.m.
On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
[...]
(and again, for the sake of argument, lets pretend that doing
anything
from a command line, or editing a text file, or researching obscure
specs about your monitor, is not an option for the users in question)
I think that for majority of monitors out there, you can find the specs
in 5 minutes using Google.
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
5:36 p.m.
Dominik 'Rathann' Mierzejewski wrote:
On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
[...]
> (and again, for the sake of argument, lets pretend that doing anything
> from a command line, or editing a text file, or researching obscure
> specs about your monitor, is not an option for the users in question)
I think that for majority of monitors out there, you can find the specs
in 5 minutes using Google.
And that is relevent to this thread how?
-dmc
5:47 p.m.
Dominik 'Rathann' Mierzejewski wrote:
On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
[...]
> (and again, for the sake of argument, lets pretend that doing anything
> from a command line, or editing a text file, or researching obscure
> specs about your monitor, is not an option for the users in question)
I think that for majority of monitors out there, you can find the specs
in 5 minutes using Google.
And then translate that into a modeline with another 3 days of googling.
--
Les Mikesell
lesmikesell(a)gmail.com
11:05 a.m.
On Monday, 03 September 2007 at 00:47, Les Mikesell wrote:
Dominik 'Rathann' Mierzejewski wrote:
>On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
>[...]
>>(and again, for the sake of argument, lets pretend that doing anything
>>from a command line, or editing a text file, or researching obscure
>>specs about your monitor, is not an option for the users in question)
>
>I think that for majority of monitors out there, you can find the specs
>in 5 minutes using Google.
And then translate that into a modeline with another 3 days of googling.
That could be easily automated, but for now:
man gtf
Regards,
R.
--
Fedora contributor http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
9:39 a.m.
On Sun, 2007-09-02 at 17:47 -0500, Les Mikesell wrote:
Dominik 'Rathann' Mierzejewski wrote:
> On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
> [...]
>> (and again, for the sake of argument, lets pretend that doing anything
>> from a command line, or editing a text file, or researching obscure
>> specs about your monitor, is not an option for the users in question)
>
> I think that for majority of monitors out there, you can find the specs
> in 5 minutes using Google.
And then translate that into a modeline with another 3 days of googling.
Why does anyone write a modeline by hand anymore?
% man cvt
- ajax
10:29 a.m.
Adam Jackson wrote:
On Sun, 2007-09-02 at 17:47 -0500, Les Mikesell wrote:
> Dominik 'Rathann' Mierzejewski wrote:
>> On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
>> [...]
>>> (and again, for the sake of argument, lets pretend that doing anything
>>> from a command line, or editing a text file, or researching obscure
>>> specs about your monitor, is not an option for the users in question)
>> I think that for majority of monitors out there, you can find the specs
>> in 5 minutes using Google.
> And then translate that into a modeline with another 3 days of googling.
Why does anyone write a modeline by hand anymore?
% man cvt
Because on the machines I'm used to using:
# man cvt
No manual entry for cvt
--
Les Mikesell
lesmikesell(a)gmail.com
10:41 a.m.
Les Mikesell wrote:
Adam Jackson wrote:
> On Sun, 2007-09-02 at 17:47 -0500, Les Mikesell wrote:
>> Dominik 'Rathann' Mierzejewski wrote:
>>> On Sunday, 02 September 2007 at 21:52, Douglas McClendon wrote:
>>> [...]
>>>> (and again, for the sake of argument, lets pretend that doing
>>>> anything from a command line, or editing a text file, or
>>>> researching obscure specs about your monitor, is not an option for
>>>> the users in question)
>>> I think that for majority of monitors out there, you can find the specs
>>> in 5 minutes using Google.
>> And then translate that into a modeline with another 3 days of googling.
>
> Why does anyone write a modeline by hand anymore?
>
> % man cvt
Because on the machines I'm used to using:
# man cvt
No manual entry for cvt
[root@elwood ~]# rpm -qf /usr/share/man/man1/cvt.1.gz
xorg-x11-server-Xorg-1.3.0.0-22.fc8
--
Kind regards,
Jeroen van Meeuwen
-kanarip
--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
11:08 a.m.
On Tue, 2007-09-04 at 10:39 -0400, Adam Jackson wrote:
Why does anyone write a modeline by hand anymore?
% man cvt
Thanks for the tip. Is there any way to fine-tune the results? On my
Sony projector TV (with HDMI input), the automatically generated
modeline (from EDID information, I might add) results in the graphics
screen going out-of-bounds of the physical display.
One of the nice things I've learned about X Windows is that the standard
resolutions (1280x1024, 800x600, 1680x1050, etc.) aren't fixed
(depending on the display device). That one can come up with arbitrary
resolutions so long as the display supports it. There was a time when I
would find the maximum resolution that my video card and display screen
could use while maintaining a refresh rate of 75Hz. It was all done by
hand and my bumbling about with numbers. Are those days gone? Or will
that capability be somehow revived through a GUI program that will take
care of the mathematical part of computing modelines (which used to be
done by hand)?
It really is too bad that the Modes can't be changed on the fly (without
needing an X restart).
--
Richi Plana
11:16 a.m.
On Tue, 2007-09-04 at 10:08 -0600, Richi Plana wrote:
On Tue, 2007-09-04 at 10:39 -0400, Adam Jackson wrote:
> Why does anyone write a modeline by hand anymore?
>
> % man cvt
Thanks for the tip. Is there any way to fine-tune the results? On my
Sony projector TV (with HDMI input), the automatically generated
modeline (from EDID information, I might add) results in the graphics
screen going out-of-bounds of the physical display.
xvidtune should still work. Sadly it's probably the nicest UI for that
atm.
I'm also working on implementing DDC/CI, so you should be able to
control many monitor adjustment parameters from the host side.
One of the nice things I've learned about X Windows is that the
standard
resolutions (1280x1024, 800x600, 1680x1050, etc.) aren't fixed
(depending on the display device). That one can come up with arbitrary
resolutions so long as the display supports it. There was a time when I
would find the maximum resolution that my video card and display screen
could use while maintaining a refresh rate of 75Hz. It was all done by
hand and my bumbling about with numbers. Are those days gone? Or will
that capability be somehow revived through a GUI program that will take
care of the mathematical part of computing modelines (which used to be
done by hand)?
That's sometimes true and sometimes not. For CRTs it's certainly still
true. LCDs almost always have a native refresh rate, and they either
have a built-in scaler or they don't. If they do, then you can feed
them different refresh rates, and they'll resample the input to their
native output frequency, but it doesn't win you anything to do so since
the screen is going to pump out 60Hz whether you want it to or not. If
the panel doesn't have a built-in scaler (which no dual-link monitor
I've seen has, and many laptop panels don't), then you pretty much have
to give it exactly the right refresh rate and an integer factor of the
native pixel size.
To compensate for that, many graphics chips have a scaler right at the
output. NVIDIA cards, for example, are pretty much always driving the
panel at the native size, and using the built-in scaler to change modes.
This was actually a deficiency in EDID version 1.3; the "ranges" section
was more or less required even though the monitor might not meaningfully
_have_ sync ranges. EDID 1.4 (which I almost have implemented parser
support for now) makes the ranges section optional, and defines how the
host software is supposed to interpret EDID blocks without ranges.
It really is too bad that the Modes can't be changed on the fly
(without
needing an X restart).
In RANDR 1.2 they can.
Ideally someone will write a usable frontend to it - so you can do mode
injection and fallback recovery with a nice pretty UI - and we'll get
all the drivers ported over to the RANDR 1.2 API. That will be winning.
- ajax
11:35 a.m.
On Tue, Sep 04, 2007 at 12:16:46PM -0400, Adam Jackson wrote:
Ideally someone will write a usable frontend to it - so you can do
mode
injection and fallback recovery with a nice pretty UI - and we'll get
all the drivers ported over to the RANDR 1.2 API. That will be winning.
Is there something remotely looking like documentation somewhere?
OG.
11:38 a.m.
On Tue, 2007-09-04 at 18:35 +0200, Olivier Galibert wrote:
On Tue, Sep 04, 2007 at 12:16:46PM -0400, Adam Jackson wrote:
> Ideally someone will write a usable frontend to it - so you can do mode
> injection and fallback recovery with a nice pretty UI - and we'll get
> all the drivers ported over to the RANDR 1.2 API. That will be winning.
Is there something remotely looking like documentation somewhere?
Not really, sadly. The new xrandr utility is pretty readable if you're
trying to do client-side bits. The driver side of the API is "look at
the intel or nv drivers and steal code".
- ajax
11:44 a.m.
On Tue, 2007-09-04 at 12:16 -0400, Adam Jackson wrote:
> It really is too bad that the Modes can't be changed on the
fly
(without
> needing an X restart).
In RANDR 1.2 they can.
Ideally someone will write a usable frontend to it - so you can do mode
injection and fallback recovery with a nice pretty UI - and we'll get
all the drivers ported over to the RANDR 1.2 API. That will be winning.
OMG. Does that mean being able to change any parameter in a given
modeline?
Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync
+vsync
^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^ ^^^^^^ ->
Any of these will be changeable on the fly?
That would be winning.
--
Richi Plana
noon
On Tue, 2007-09-04 at 10:44 -0600, Richi Plana wrote:
On Tue, 2007-09-04 at 12:16 -0400, Adam Jackson wrote:
> > It really is too bad that the Modes can't be changed on the fly
> (without
> > needing an X restart).
>
> In RANDR 1.2 they can.
>
> Ideally someone will write a usable frontend to it - so you can do mode
> injection and fallback recovery with a nice pretty UI - and we'll get
> all the drivers ported over to the RANDR 1.2 API. That will be winning.
OMG. Does that mean being able to change any parameter in a given
modeline?
Modeline "1280x1024" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync
+vsync
^^^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^ ^^^^^^ ^^^^^^
-> Any of these will be changeable on the fly?
From 'xrandr -h':
--newmode <name> <clock MHz>
<hdisp> <hsync-start> <hsync-end> <htotal>
<vdisp> <vsync-start> <vsync-end> <vtotal>
[+HSync] [-HSync] [+VSync] [-VSync]
- ajax
12:33 p.m.
On Tue, 2007-09-04 at 13:00 -0400, Adam Jackson wrote:
>From 'xrandr -h':
--newmode <name> <clock MHz>
<hdisp> <hsync-start> <hsync-end> <htotal>
<vdisp> <vsync-start> <vsync-end> <vtotal>
[+HSync] [-HSync] [+VSync] [-VSync]
Sorry ... am on F7 and it wasn't appearing in xrandr in
xorg-x11-server-utils-7.2-1.fc7.x86_64 .. That is tres cool. Now to
figure out what those values mean again. If someone could write a GUI
with the parameters in English (with translations, of course) with
sliders while updating in real/run-time, we'd be golden. It'd be a step
further than even Ubuntu's Bulletproof-X ;) (assuming they don't end up
destroying their hardware)
--
Richi Plana
11:31 a.m.
Hi,
> % man cvt
Thanks for the tip. Is there any way to fine-tune the results? On my
Sony projector TV (with HDMI input), the automatically generated
modeline (from EDID information, I might add) results in the graphics
screen going out-of-bounds of the physical display.
xorg-x11-server-utils has an old program called xvidtune, that
provides a UI for doing little adjustments.
When you're all done, ther'e's "Show" button that prints out the
modeline to terminal.
--Ray
11:33 a.m.
On Tue, Sep 04, 2007 at 10:08:59AM -0600, Richi Plana wrote:
It really is too bad that the Modes can't be changed on the fly
(without
needing an X restart).
They can, kindasorta, with XFree86-VidModeExtension. xvidtune uses
it. IIRC one value is not tunable easily, the pixel clock maybe. And
the driver can refuse.
OG.
6:30 p.m.
On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
Honestly I can't vouch that this is ever the case. It is pure
speculation on my part. But I for one get sick of hearing "you're
hardware is broken, go suck an egg", when clearly that hardware is not
broken enough to not work on windows, using the mechanisms they have in
place (e.g. presumably reading the data from the driver cd).
Okay.... here is where the conversation stops. If this is complete
speculation..then there is no constructive way forward. Adam Jackson
has already commented that in his opinion what is provided in the inf
files is not enough to fix the problem. I strongly suggest that you
go re-read everything that he wrote concerning the history of Fedora's
usage of the code Ubuntu is relying on now to parse inf files. Read
it... read it again.. and then when you think you understand it...read
it again.
Now.. it is up to anyone who disagrees with Mr. Jackson's informed
historical account of the usefulness of inf parsing.. to dig out an
inf file for a specific piece of hardware that doesn't currently work
with Fedora's auto-detection and show...specifically..that the
information provided in the inf file is enough to fix the issues that
Mr. Jackson has stated can't be resolved with information from the inf
file. Stop arguing that the inf should have the information
necessary.. .and start showing that they do.
(and again, for the sake of argument, lets pretend that doing anything
from a command line, or editing a text file, or researching obscure
specs about your monitor, is not an option for the users in question)
I FORBID arguments for arguments sake. If you want to argue with me
about that, i suggest we open up a fedora-arguments-list.
But again, this is speculation on my part. Please correct me if
I'm
wrong. :)
Adam Jackson has previously done just that... he wrote quite
succinctly that information in inf files is not enough to solve the
underlying problems.
-jef
6:51 p.m.
Jeff Spaleta wrote:
Now.. it is up to anyone who disagrees with Mr. Jackson's
informed
historical account of the usefulness of inf parsing.. to dig out an
inf file for a specific piece of hardware that doesn't currently work
with Fedora's auto-detection and show...specifically..that the
information provided in the inf file is enough to fix the issues that
Mr. Jackson has stated can't be resolved with information from the inf
file. Stop arguing that the inf should have the information
necessary.. .and start showing that they do.
Isn't the fact that windows works with them a pretty good demonstration?
I FORBID arguments for arguments sake. If you want to argue with me
about that, i suggest we open up a fedora-arguments-list.
OK, where do we sign up?
Adam Jackson has previously done just that... he wrote quite
succinctly that information in inf files is not enough to solve the
underlying problems.
Is he suggesting that windows uses magic? I thought he meant instead
that X doesn't use the information sensibly.
--
Les Mikesell
lesmikesell(a)gmail.com
7:46 p.m.
On 9/2/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Isn't the fact that windows works with them a pretty good
demonstration?
Sadly we don't have access to that source code now do we. Please keep
the rhetorical comments to a minimum.
Go back and read what Mr. Jackson wrote...again. There is a specific
piece of code involved in the parsing of inf files that Ubuntu is
making use of. The scope of the discussion is grounded in how that
piece of code parses inf files and whether or not the information it
parses out of the file in sufficient to solve the problems linux users
maybe having with hardware detection. Show specifically that the
information THAT piece of code pulls out of the inf file is enough to
solve the problems needed to make things work like you expect inside
X. If there is information in the inf file that piece of code doesn't
make use of correctly... feel free to point that. If you run across in
bugs in Xorg's X11 server in the process feel free to point those out
as well.
Is he suggesting that windows uses magic? I thought he meant
instead
that X doesn't use the information sensibly.
Are you asking me to-reinterpret Mr. Jackson's statements for
additional implied meaning?
Let me humbly suggest that making it a point to ask 3rd parties to
read implied meanings into other people's comments is a sure way to
create continued miscommunication and is not an inherently
constructive activity.
Stop trolling for divisive commentary, and start bringing technical
specifics to the table. If you actually care about the user
experience, more than you care about arguing about the user
experience, you will start addressing the technical limitations of the
codebase in question.
-jef"the wheels on the bus go 'round and 'round, 'round and 'round,
'round and 'round. The pointlessly long discussion with no technical
merit go 'round and 'round, 'round and 'round"spaleta
8:34 p.m.
Jeff Spaleta wrote:
On 9/2/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> Isn't the fact that windows works with them a pretty good demonstration?
Sadly we don't have access to that source code now do we. Please keep
the rhetorical comments to a minimum.
Seems pretty objective to me...
> Is he suggesting that windows uses magic? I thought he meant
instead
> that X doesn't use the information sensibly.
Are you asking me to-reinterpret Mr. Jackson's statements for
additional implied meaning?
Yes, in particular:
"So you end up in some pretty hilarious situations, because
X prefers width over height, so even though your monitor's
1600x1200, the sync range is big enough to fit 1680x1050,
so you'll try to fit that, and lose."
I interpret that as an X issue, not a lack of information in the inf file.
Stop trolling for divisive commentary,
Telling other people what to do is about as divisive as you can get -
and it doesn't work.
--
Les Mikesell
lesmikesell(a)gmail.com
9:48 a.m.
On Sun, 2007-09-02 at 20:34 -0500, Les Mikesell wrote:
Jeff Spaleta wrote:
> On 9/2/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
>> Isn't the fact that windows works with them a pretty good demonstration?
>
> Sadly we don't have access to that source code now do we. Please keep
> the rhetorical comments to a minimum.
Seems pretty objective to me...
Windows does almost exactly what we do. It uses the EDID information if
it can be found, otherwise it constructs a list of candidate modes based
on sync ranges. Some of them will be out of range for the monitor; it
happens to have better UI for reverting to the older settings.
>> Is he suggesting that windows uses magic? I thought he
meant instead
>> that X doesn't use the information sensibly.
>
> Are you asking me to-reinterpret Mr. Jackson's statements for
> additional implied meaning?
Please, call me ajax. The only people who call me Adam or Mr. Jackson
are telemarketers and judges.
Yes, in particular:
"So you end up in some pretty hilarious situations, because
X prefers width over height, so even though your monitor's
1600x1200, the sync range is big enough to fit 1680x1050,
so you'll try to fit that, and lose."
I interpret that as an X issue, not a lack of information in the inf file.
It's debatable whether that logic in X is a bug or not. It's certainly
correct when sorting modes smaller than the native screen size: your
field of vision is much wider than it is tall, so X should prefer wider
modes.
You only ever hit it as a bug in configuration when X can't query the
monitor for its native aspect ratio, and you only manually specify sync
ranges.
The inf file does not give you aspect ratio. It only gives you sync
ranges.
- ajax
11:36 a.m.
Adam Jackson wrote:
Windows does almost exactly what we do. It uses the EDID information
if
it can be found, otherwise it constructs a list of candidate modes based
on sync ranges. Some of them will be out of range for the monitor; it
happens to have better UI for reverting to the older settings.
Were there ever versions of the X configurator that made changes on the
fly and reverted if you didn't confirm that it worked or am I confusing
this with some other old box?
--
Les Mikesell
lesmikesell(a)gmail.com
5:49 a.m.
On Sun, 2007-09-02 at 16:46 -0800, Jeff Spaleta wrote:
On 9/2/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
> Isn't the fact that windows works with them a pretty good demonstration?
Sadly we don't have access to that source code now do we. Please keep
the rhetorical comments to a minimum.
Jeff I think you missed the point....
which can best be described as:
OMG!! Ubuntu OMG!!
Dave.
8:41 p.m.
Jeff Spaleta wrote:
On 9/2/07, Douglas McClendon
<dmc.fedora(a)filteredperception.org> wrote:
> Honestly I can't vouch that this is ever the case. It is pure
> speculation on my part. But I for one get sick of hearing "you're
> hardware is broken, go suck an egg", when clearly that hardware is not
> broken enough to not work on windows, using the mechanisms they have in
> place (e.g. presumably reading the data from the driver cd).
Okay.... here is where the conversation stops. If this is complete
speculation..then there is no constructive way forward. Adam Jackson
has already commented that in his opinion what is provided in the inf
files is not enough to fix the problem. I strongly suggest that you
go re-read everything that he wrote concerning the history of Fedora's
usage of the code Ubuntu is relying on now to parse inf files. Read
it... read it again.. and then when you think you understand it...read
it again.
Here is the part that confuses me-
"
The whole reason we're _not_ using this very much - and that I've
effectively stopped updating MonitorsDB - is because the inf files don't
give you useful information. They give you sync ranges and that's about
it. So you end up in some pretty hilarious situations, because X
prefers width over height, so even though your monitor's 1600x1200, the
sync range is big enough to fit 1680x1050, so you'll try to fit that,
and lose.
"
This, please correct me if I'm wrong, is the relevant portion of the
indisputable Mr Jackson's claim.
I personally focus on this portion-
"
They give you sync ranges and that's about
it.
"
To me, that seems like it might be enough. The fact that ubuntu is
investing so much energy in this, makes me suggest that there might be
something to it.
The indisputable Mr. Jackson's followup as to why this is useless is
"
So you end up in some pretty hilarious situations, because X
prefers width over height, so even though your monitor's 1600x1200, the
sync range is big enough to fit 1680x1050, so you'll try to fit that,
and lose.
"
Which sounds really stupid to me. It sounds like a trivial thing to me,
to modify X so that it doesn't exclusively prefer width over height,
resulting in the "hilarious situation" described.
Honestly it doesn't sound very hard at all to modify X so that it
understands that 1600x1200 is more preferable than 1680x1050.
With that improvement, going only by my speculation, and the
indisputable opinions/facts provided by Mr Jackson, I suspect there is
room for value in the ubuntu-bulletproof-x method.
Now, I didn't reread the indisputable Mr. Jackson's claims the 5 times
that you suggested. Please feel free to ban me from this list, if you
feel that I have nothing to offer the technical discussion.
Regards,
-dmc
9:17 p.m.
On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
To me, that seems like it might be enough. The fact that ubuntu is
investing so much energy in this, makes me suggest that there might be
something to it.
We've no idea how much "energy" Ubuntu is investing in this. We do
know they are re-using code available in hwdata as seen in rhl/fedora.
Which sounds really stupid to me. It sounds like a trivial thing to
me,
to modify X so that it doesn't exclusively prefer width over height,
resulting in the "hilarious situation" described.
Honestly it doesn't sound very hard at all to modify X so that
it
understands that 1600x1200 is more preferable than 1680x1050.
Go back and read what Mr. Jackson wrote..again...specifically the
on-going work concerning using the maximum pixel clock setting to
discriminate modes.
With that improvement, going only by my speculation, and the
indisputable opinions/facts provided by Mr Jackson, I suspect there is
room for value in the ubuntu-bulletproof-x method.
Or perhaps there's none at all, and the work being done to expose inf
file reading is a dead-end. Until we have a specific example inf file
situation to discuss, it's impossible to go any further in this
discussion. In any event I look forward to seeing Ubuntu supplied
patches to Xorg to "fix" X so that we can all benefit from better
hardware detection.
-jef
9:40 p.m.
Jeff Spaleta wrote:
On 9/2/07, Douglas McClendon
<dmc.fedora(a)filteredperception.org> wrote:
> To me, that seems like it might be enough. The fact that ubuntu is
> investing so much energy in this, makes me suggest that there might be
> something to it.
We've no idea how much "energy" Ubuntu is investing in this. We do
know they are re-using code available in hwdata as seen in rhl/fedora.
Cmon man. The fact that you see so much press about 'bulletproof-x'
does give you "an idea" about how much "energy" ubuntu is investing in
this.
No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you
something.
> Which sounds really stupid to me. It sounds like a trivial thing to me,
> to modify X so that it doesn't exclusively prefer width over height,
> resulting in the "hilarious situation" described.
> Honestly it doesn't sound very hard at all to modify X so that it
> understands that 1600x1200 is more preferable than 1680x1050.
Go back and read what Mr. Jackson wrote..again...specifically the
on-going work concerning using the maximum pixel clock setting to
discriminate modes.
Why?
Is there something in there describing how that work can automagically
recreate the information that cannot be retrieved from a 'broken' edid
hardware implementation, in which the data in the inf is correct? Going
beyond 'speculation', I did a little googling, and found these two
posts, which seem to suggest that the situation Olivier Galibert
described, and which I have speculated, is a real scenario-
http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html
http://www.nvnews.net/vbulletin/showthread.php?t=83575
Again, I don't claim to be an X hacker, but it sounds like there are
legitimate situations in which there is *NO* way for the X driver to
autodetect the monitor specs, while *AT THE SAME TIME* it is possible to
get useful information from inf files.
Again, I could be wrong, but I really do think your telling me to STFU
was uncalled for.
> With that improvement, going only by my speculation, and the
> indisputable opinions/facts provided by Mr Jackson, I suspect there is
> room for value in the ubuntu-bulletproof-x method.
Or perhaps there's none at all, and the work being done to expose inf
file reading is a dead-end. Until we have a specific example inf file
situation to discuss, it's impossible to go any further in this
discussion. In any event I look forward to seeing Ubuntu supplied
patches to Xorg to "fix" X so that we can all benefit from better
hardware detection.
And perhaps, if fedora actually respected ubuntu, and kept up with their
advances, rather than exclusively playing catch up, they wouldn't be
having their asses handed to them.
Yes, I know redhat has learned well from microsoft, that the way to be
successful is to let others do the expensive trailblazing, and then only
copy the trails that led to success, rather than those that led to
failure. I have no problem with that attitude, I think it is
intelligent. But please, this is just a mailinglist where people
routinely talk about blowing goats. So don't tell me to STFU like the
rest of the people on this list can't handle the signal/noise ratio.
-dmc
10:25 p.m.
On Sun, 2007-09-02 at 21:40 -0500, Douglas McClendon wrote:
Jeff Spaleta wrote:
> On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
>> To me, that seems like it might be enough. The fact that ubuntu is
>> investing so much energy in this, makes me suggest that there might be
>> something to it.
>
> We've no idea how much "energy" Ubuntu is investing in this. We do
> know they are re-using code available in hwdata as seen in rhl/fedora.
Cmon man. The fact that you see so much press about 'bulletproof-x'
does give you "an idea" about how much "energy" ubuntu is investing
in this.
No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you
something.
>
>> Which sounds really stupid to me. It sounds like a trivial thing to me,
>> to modify X so that it doesn't exclusively prefer width over height,
>> resulting in the "hilarious situation" described.
>
>> Honestly it doesn't sound very hard at all to modify X so that it
>> understands that 1600x1200 is more preferable than 1680x1050.
>
> Go back and read what Mr. Jackson wrote..again...specifically the
> on-going work concerning using the maximum pixel clock setting to
> discriminate modes.
Why?
Is there something in there describing how that work can automagically
recreate the information that cannot be retrieved from a 'broken' edid
hardware implementation, in which the data in the inf is correct? Going
beyond 'speculation', I did a little googling, and found these two
posts, which seem to suggest that the situation Olivier Galibert
described, and which I have speculated, is a real scenario-
http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html
http://www.nvnews.net/vbulletin/showthread.php?t=83575
Again, I don't claim to be an X hacker, but it sounds like there are
legitimate situations in which there is *NO* way for the X driver to
autodetect the monitor specs, while *AT THE SAME TIME* it is possible to
get useful information from inf files.
Again, I could be wrong, but I really do think your telling me to STFU
was uncalled for.
>
>> With that improvement, going only by my speculation, and the
>> indisputable opinions/facts provided by Mr Jackson, I suspect there is
>> room for value in the ubuntu-bulletproof-x method.
>
> Or perhaps there's none at all, and the work being done to expose inf
> file reading is a dead-end. Until we have a specific example inf file
> situation to discuss, it's impossible to go any further in this
> discussion. In any event I look forward to seeing Ubuntu supplied
> patches to Xorg to "fix" X so that we can all benefit from better
> hardware detection.
And perhaps, if fedora actually respected ubuntu, and kept up with their
advances, rather than exclusively playing catch up, they wouldn't be
having their asses handed to them.
Yes, I know redhat has learned well from microsoft, that the way to be
successful is to let others do the expensive trailblazing, and then only
copy the trails that led to success, rather than those that led to
failure. I have no problem with that attitude, I think it is
intelligent. But please, this is just a mailinglist where people
routinely talk about blowing goats. So don't tell me to STFU like the
rest of the people on this list can't handle the signal/noise ratio.
You obviously don't know much about Ubuntu's development model or where
most of their innovations actually come from, yes there is a problem
here with Fedora, but it isn't the problem you think it is...
Dave.
10:42 p.m.
On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
Jeff Spaleta wrote:
> On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
>> To me, that seems like it might be enough. The fact that ubuntu is
>> investing so much energy in this, makes me suggest that there might be
>> something to it.
>
> We've no idea how much "energy" Ubuntu is investing in this. We do
> know they are re-using code available in hwdata as seen in rhl/fedora.
Cmon man. The fact that you see so much press about 'bulletproof-x'
does give you "an idea" about how much "energy" ubuntu is investing
in this.
No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you
something.
I'm not much a fan of the "pop" thing, more interested in the
"right" thing.
[ snip ]
And perhaps, if fedora actually respected ubuntu, and kept up with
their
advances, rather than exclusively playing catch up, they wouldn't be
having their asses handed to them.
What exactly are you talking about? Besides the fact that Fedora and
Ubuntu aren't in competition, you seem to have something in mind.
Please share.
Yes, I know redhat has learned well from microsoft, that the way to
be
successful is to let others do the expensive trailblazing, and then only
copy the trails that led to success, rather than those that led to
failure.
Feel free to ask some kernel maintainer how much Canonical contributes
to the kernel.
I have no problem with that attitude, I think it is
intelligent. But please, this is just a mailinglist where people
routinely talk about blowing goats.
That's way beyond an exaggeration.
So don't tell me to STFU like the
rest of the people on this list can't handle the signal/noise ratio.
I can't. There's way too much noise on this particular thread.
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
11:18 p.m.
Arthur Pemberton wrote:
On 9/2/07, Douglas McClendon
<dmc.fedora(a)filteredperception.org> wrote:
[ snip ]
> And perhaps, if fedora actually respected ubuntu, and kept up with their
> advances, rather than exclusively playing catch up, they wouldn't be
> having their asses handed to them.
What exactly are you talking about? Besides the fact that Fedora and
Ubuntu aren't in competition, you seem to have something in mind.
Please share.
Fedora and Ubuntu aren't in competition?
You really don't think there are a significant number of linux users,
who make a choice between installing and using fedora, vs installing and
using ubuntu?
Really?
I'll admit that every project/enterprise can be a non-zero-sum game
where users are attracted that were not previously using a similar
product/project. But to claim that there is no competition for users
between fedora and ubunutu is ludicrous,
IM-not-as-humble-as-it-ought-to-be-O.
> Yes, I know redhat has learned well from microsoft, that the way to be
> successful is to let others do the expensive trailblazing, and then only
> copy the trails that led to success, rather than those that led to
> failure.
Feel free to ask some kernel maintainer how much Canonical contributes
to the kernel.
And what percentage of lines of code in fedora is the kernel?
kernel != distro.
I'm not saying you don't have a valid point. But in the open source
world, where everybody is sharing yesterday's work equally, because that
is the beauty of it, the question is "what have you done for me lately?"
It would seem... that going by the number of users ubuntu is pulling
in, that they have been doing something for their users. Something that
IMO, fedora would be wise to respect and emulate. I don't care if you
disagree, that is just what I think. Note, I don't mean emulate to the
point of changing what fedora has learned to do right, over it's long
history. I just mean that ajax's original response, sounded an aweful
lot like "these ubuntu folks are just marketing work that we did". When
in fact, after a little digging at the real issue, it becomes apparent
that in order to make something "bulletproof", you have to be willing to
do some things that for perhaps quite valid reasons, ajax and fedora
seem quite unwilling to do. (i.e. use data from inf file on windows
driver cd, at the expense of that tactic lowering the pressure on
monitor manufacturers to not ship monitors with non existent, or non
working edid implementations).
> I have no problem with that attitude, I think it is
> intelligent. But please, this is just a mailinglist where people
> routinely talk about blowing goats.
That's way beyond an exaggeration.
Yes, but it was kind of funny wasn't it :)
> So don't tell me to STFU like the
> rest of the people on this list can't handle the signal/noise ratio.
I can't. There's way too much noise on this particular thread.
And you are participating, rather than ignoring it because...?
I presume you do use a threaded email reader? Or at least can visually
ignore a topic based on subject line?
-dmc
12:04 a.m.
On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
Arthur Pemberton wrote:
> On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
> [ snip ]
>
>> And perhaps, if fedora actually respected ubuntu, and kept up with their
>> advances, rather than exclusively playing catch up, they wouldn't be
>> having their asses handed to them.
>
>
> What exactly are you talking about? Besides the fact that Fedora and
> Ubuntu aren't in competition, you seem to have something in mind.
> Please share.
Fedora and Ubuntu aren't in competition?
I would say not. Unless the Ubuntu people think they are competing
against Fedora.
You really don't think there are a significant number of linux
users,
who make a choice between installing and using fedora, vs installing and
using ubuntu?
They might be. But I wouldn't consider that competition. I've never
gone "darn" I wish user Joe had gone with Fedora.
The only real problem I have with a user choosing Fedora is that I
cannot help them much if they do, since I've never used it, nor really
intend to.
Really?
Yes really.
I'll admit that every project/enterprise can be a non-zero-sum
game
where users are attracted that were not previously using a similar
product/project. But to claim that there is no competition for users
between fedora and ubunutu is ludicrous,
IM-not-as-humble-as-it-ought-to-be-O.
Well I don't really see competition for users as a real competition.
And I certainty don't see any effort on Fedora side being put in to
attract users (for better or worse) Maybe Ubuntu team really thinks
there is some serious competition going on, I guess that would explain
some things.
>> Yes, I know redhat has learned well from microsoft, that the
way to be
>> successful is to let others do the expensive trailblazing, and then only
>> copy the trails that led to success, rather than those that led to
>> failure.
>
>
> Feel free to ask some kernel maintainer how much Canonical contributes
> to the kernel.
And what percentage of lines of code in fedora is the kernel?
kernel != distro.
I'm glad you point that out. Seems like things Fedora do are more
globally useful than what Ubuntu does. Since, for example,
advancements to the kernel help everyone, advancements to the Ubuntu
distro help mostly Ubuntu.
I'm not saying you don't have a valid point. But in the open
source
world, where everybody is sharing yesterday's work equally, because that
is the beauty of it, the question is "what have you done for me lately?"
Ok
It would seem... that going by the number of users ubuntu is
pulling
in, that they have been doing something for their users. Something that
IMO, fedora would be wise to respect and emulate.
Respect maybe... I'm not really sure about the emulate part.
I don't care if you
disagree, that is just what I think.
Ok
Note, I don't mean emulate to the
point of changing what fedora has learned to do right, over it's long
history. I just mean that ajax's original response, sounded an aweful
lot like "these ubuntu folks are just marketing work that we did". When
in fact, after a little digging at the real issue, it becomes apparent
that in order to make something "bulletproof", you have to be willing to
do some things that for perhaps quite valid reasons, ajax and fedora
seem quite unwilling to do. (i.e. use data from inf file on windows
driver cd, at the expense of that tactic lowering the pressure on
monitor manufacturers to not ship monitors with non existent, or non
working edid implementations).
Ok... I guessing calling it "bulletproof" anything just screams
marketing to some people
>> I have no problem with that attitude, I think it is
>> intelligent. But please, this is just a mailinglist where people
>> routinely talk about blowing goats.
>
>
> That's way beyond an exaggeration.
Yes, but it was kind of funny wasn't it :)
It wasn't a very picture for my mind actually.
>> So don't tell me to STFU like the
>> rest of the people on this list can't handle the signal/noise ratio.
>
>
> I can't. There's way too much noise on this particular thread.
And you are participating, rather than ignoring it because...?
I ignored it at first, that's why the noise got to high. Should have
made attention from the start. The subject didn't seem constructive,
but the lifespan of the thread got me interesting
I presume you do use a threaded email reader? Or at least can
visually
ignore a topic based on subject line?
Yes and Yes
-dmc
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
12:43 a.m.
New subject: globally useful vs. useful for the distribution (was: Re: ubuntu bulletproof x)
On 03.09.2007 07:04, Arthur Pemberton wrote:
On 9/2/07, Douglas McClendon
<dmc.fedora(a)filteredperception.org> wrote:
> Arthur Pemberton wrote:
>> On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
[...]
>>> Yes, I know redhat has learned well from microsoft, that the way to be
>>> successful is to let others do the expensive trailblazing, and then only
>>> copy the trails that led to success, rather than those that led to
>>> failure.
>> Feel free to ask some kernel maintainer how much Canonical contributes
>> to the kernel.
> And what percentage of lines of code in fedora is the kernel?
> kernel != distro.
I'm glad you point that out. Seems like things Fedora do are more
globally useful than what Ubuntu does.
+1
And that's at least *afaics* not only true for Kernel-Space, but for
other areas as well.
Since, for example,
advancements to the kernel help everyone, advancements to the Ubuntu
distro help mostly Ubuntu.
Agreed as well. But I think we in Fedora-Land should put "advancements
to the Fedora distro" *a bit higher* on our todo-List as well, as
especially those things are what make a distro cool and "nice to use"
(and thus influence the decision what distro to use).
Faster system-start comes to my mind (which in parts is globally useful
as well), support for encrypted filesystems in the installer, real
"minimal"-installs, avoiding unnecessary dependencies/bloat , avoiding
broken deps in the repo, Partition resizing in the installer and lots of
(often small) similar things.
CU
knurd
8:37 a.m.
On 2007-09-03, 04:18 GMT, Douglas McClendon wrote:
> Feel free to ask some kernel maintainer how much Canonical
> contributes
> to the kernel.
And what percentage of lines of code in fedora is the kernel?
kernel != distro.
The same question could be I am afraid asked about Canonical's
contribution to X, I am afraid, which is much closer to the topic
of this thread.
Matej
10:48 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Douglas McClendon wrote:
And perhaps, if fedora actually respected ubuntu, and kept up with
their
advances, rather than exclusively playing catch up, they wouldn't be
having their asses handed to them.
I sense something amiss here when you say "respect". The fact remains
that there are almost always more than one way to resolve a particular
problem and according what I interpret of ajax's mail the way of
choosing .inf files is kind of tricky. At a very broad level there would
be considerable overlap in terms of work, innovation being pushed by
various distributions into the upstream. I believe that reading the
infrequent mails on this from Max, Rahul et al would be self explanatory.
Let me share a personal experience here - for the better part of the
first 3 years of using Linux (and constantly shifting between newer
releases from Red Hat, Mandrake and SuSE) I was stuck with a X that
refused to behave as expected all because of a SiS card. Would an .inf
file reading "Bulletproof" idea helped then ? If you had asked me then
I'd have mostly agreed. Now, I don't think so. There are multiple
reasons why, but barring the technical ones which ajax is qualified to
comment on, the reason I see is that we would send a strong signal to
outside ODMs that it is proper not to do code push for Linux and
software engineers on Linux can reverse engineer the black box. That is
what I perceive as a very slippery slope. It starts off from X (and
monitor configuration) which impacts the end user - but it has the
potential to reacher deeper invasive depths at various levels where
drivers and driver CDs for Windows just solve the problem while Linux
struggles. *That* is something we really don't want.
Yes, I know redhat has learned well from microsoft, that the way to
be
successful is to let others do the expensive trailblazing, and then only
copy the trails that led to success, rather than those that led to
failure. I have no problem with that attitude, I think it is
intelligent. But please, this is just a mailinglist where people
routinely talk about blowing goats. So don't tell me to STFU like the
rest of the people on this list can't handle the signal/noise ratio.
I did not read it as people asking you to STFU. I'd rather say it was
more of a request to step back and reasonably assess the choice. More
often than not these days I see this choice between being pragmatic
(let's just get this darn thing to work and shunt aside some of the
niggling worries related to licenses and the like) and being dogmatic
(let's not forget that there is only way to solve the issue and that is
by collaborating with upstream in a transparent manner). I'd have to say
that over the years I have been using Linux, I am happy to see that
being dogmatic does help.
- --
You see things; and you say 'Why?';
But I dream things that never were;
and I say 'Why not?' - George Bernard Shaw
www.linkedin.com/in/sankarshan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG24QSXQZpNTcrCzMRAhGyAKCHavmz/5f9AbNhQYfW5NM5mePdwACfXoTB
W02Qmn5XW/6pioCSjmzRc+0=
=hd91
-----END PGP SIGNATURE-----
10:57 p.m.
On 9/2/07, Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
Cmon man. The fact that you see so much press about
'bulletproof-x'
does give you "an idea" about how much "energy" ubuntu is investing
in this.
Nope.
No, it doesn't tell you $1k, or $5k, or $250k, but it does tell you
something.
Yes, it tells me that people are interested in the problem space.. and
that perception counts for a lot.
Is there something in there describing how that work can
automagically
recreate the information that cannot be retrieved from a 'broken' edid
hardware implementation, in which the data in the inf is correct? Going
beyond 'speculation', I did a little googling, and found these two
posts, which seem to suggest that the situation Olivier Galibert
described, and which I have speculated, is a real scenario-
http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html
Perhaps you missed some very important points in this specific url you
posted. First of all that post is from Mike Harris, who was employed
by red hat at the time of that post. So approximately 2 years ago at
least one redhatter, who was working with Xorg upstream development
was thinking hard about this problem. This is noteworthy and
significant concerning the history of developing a solution in the
problem space. Again I'll point out that Mike references the same inf
parsing script that Adam referenced.
More importantly he said in that very posting that you qoute that
using the inf information in the specific case being looked at in the
thread didn't actually solve the issue. Because the information in the
inf file is not sufficient to correct the issue being experienced. And
that's the main thrust here in this thread.
Inf information is not sufficient. Mr. Jackson is working to solve
the issue of dealing with hardware detection, even working around
broken EDID, in a more general way..as part of the ongoing Xorg
development process.
Please avoid referencing binary only drivers. It only complicates
matters because we can't actually examine the code.
Again, I could be wrong, but I really do think your telling me to
STFU
was uncalled for.
I asked you to bring technical arguments to the discussion so that we
can move it forward. Continuing to re-iterate that you feel a certain
technical implementation is appropriate doesn't move things forward. I
did not ask you to shut up... I asked you to start providing
information which moves the discussion forward.
And perhaps, if fedora actually respected ubuntu, and kept up with
their
advances, rather than exclusively playing catch up, they wouldn't be
having their asses handed to them.
I'm not convinced Fedora is playing catch-up in technical
achievements. What we are playing catch-up in is perception, no doubts
about that. And for all the Fedora developers who are currently
reading this thread. I want to take this opportunity to make sure I
stress the importance of making the time to use the evolving Fedora
Feature Roadmapping process, for as much of the work that you are
doing in Fedora and upstream. I realize that some of you may consider
the Feature roadmapping process as a distraction from getting the hard
technical work done. But its one of our best tools to praise the work
you are doing in the context of the larger distribution goals.
-jef
11:15 p.m.
Jeff Spaleta wrote:
>
http://lists.freedesktop.org/pipermail/xorg/2005-October/010716.html
More importantly he said in that very posting that you qoute that
using the inf information in the specific case being looked at in the
thread didn't actually solve the issue.
Which part of the message says this?
Because the information in the
inf file is not sufficient to correct the issue being experienced.
And
that's the main thrust here in this thread.
Again, please elaborate. I'm not seeing this at all.
What I see is this-
"
> building monitors that "just work" will get that
reputation, and
> be rewarded... and those that don't... Well, they'll learn or perish.
And... market forces being what they are, the manufacturers
You think Dell is going to perish? I'd put my money on the
opposite. I'll go as far as to claim that Dell could probably
make their monitor EDID information random numbers and only
affect their sales slightly if at all.
Well.. That may be true for other reasons. Windows drivers look
^^^^^^^^^^^^^^^^^^^^^
at the shipped .inf files, or the .inf files fetch off the internet.
^^^^^^^^^^^^^^^^^^^^^^^^^
They are heavily invested into the Windows market: it's a large part
of their sales share. But assuming they weren't: shipping bad EDID
information would be a real hit for them.
"
and this
"
Even if such monitors are rare, they're not so rare when they're
shipped by one of the largest computer manufacturers in mass
volume. Even if only 10000 users experience such a problem, that
is about 1000 bug reports to wade through from angry users who
have hardware that "just works fine in Windows, and in all previous
X releases".
Ok.... so... we should come up with a .inf file parser... :-(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"
Inf information is not sufficient. Mr. Jackson is working to solve
the issue of dealing with hardware detection, even working around
broken EDID, in a more general way..as part of the ongoing Xorg
development process.
Another technical aspect, that I can point out regarding my
understanding of Mr Jackson's point is this-
His solution involves the user selecting generic monitors based on
resolutions.
I would argue, that there is (perhaps only valid for the users ubuntu is
targeting) a signifigant number of users, that don't want to
a) try to figure out the exact model number of their monitor
or
b) figure out the exact resolution their monitor supports
when if they could instead just pop the windows driver cd that came with
the monitor into the cdrom.
-dmc
11:22 p.m.
On 9/2/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
Perhaps you missed some very important points in this specific url
you
posted. First of all that post is from Mike Harris, who was employed
by red hat at the time of that post. So approximately 2 years ago at
least one redhatter, who was working with Xorg upstream development
was thinking hard about this problem. This is noteworthy and
significant concerning the history of developing a solution in the
problem space. Again I'll point out that Mike references the same inf
parsing script that Adam referenced.
Correction.... I should have said:
the thread from which your url comes from.
I've inadvertently confused things with my mis-statement.
Start reading the thread from:
http://lists.freedesktop.org/pipermail/xorg/2005-October/010706.html
and that should provide enough context. Though you are free to read
all of the thread
starting at:
http://lists.freedesktop.org/pipermail/xorg/2005-October/010673.html
-jef
11:44 p.m.
Jeff Spaleta wrote:
On 9/2/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> Perhaps you missed some very important points in this specific url you
> posted. First of all that post is from Mike Harris, who was employed
> by red hat at the time of that post. So approximately 2 years ago at
> least one redhatter, who was working with Xorg upstream development
> was thinking hard about this problem. This is noteworthy and
> significant concerning the history of developing a solution in the
> problem space. Again I'll point out that Mike references the same inf
> parsing script that Adam referenced.
Correction.... I should have said:
the thread from which your url comes from.
I've inadvertently confused things with my mis-statement.
Start reading the thread from:
http://lists.freedesktop.org/pipermail/xorg/2005-October/010706.html
and that should provide enough context.
I still remain unconvinced. In this post, Mike Harris is not claiming
that the info from the .inf file is *NEVER* useful. Only that in this
"particular" case, it is of no help.
In fact, I find his use of quotation in 'or "can work" in X' to indicate
that he understands that what he is saying is not an absolute.
Specifically-
"
In general, you can expect that just because something works in
Windows, doesn't mean anything about wether or not it works in
X, or "can work" in X, because the source code for the driver
in Windows is not the same source code for the driver in X.
You can make the drivers in X do anything they can do in Windows,
by fixing the driver to not have bugs.
"
What I read from that is *NOT* that there is *ZERO* potential use of
linux reading .inf files. Maybe that is how you read it.
Again, I have a feeling that you and I are arguing far too much about
something that is outside each of our areas of expertise. But again,
when people say something like this to me-
"
Okay.... here is where the conversation stops.
"
I tend to not shut up.
I feel that even my 'speculation' was valid content for this
mailinglist, and you stated otherwise. I disagreed. Good night.
-dmc
Though you are free to read
all of the thread
starting at:
http://lists.freedesktop.org/pipermail/xorg/2005-October/010673.html
-jef
12:49 a.m.
Le dimanche 02 septembre 2007 à 18:17 -0800, Jeff Spaleta a écrit :
Or perhaps there's none at all, and the work being done to expose
inf
file reading is a dead-end.
Anyway people concerned about inf files better mount a task force and
get info about the main screen manufacturers in the hardwaredb before
the release. That's so much friendlier than having users do the parsing
themselves.
--
Nicolas Mailhot
2:59 p.m.
On Sun, Sep 02, 2007 at 02:24:06PM +0200, Matej Cepl wrote:
Concerning the former, I don't understand how would information
provided to Windows by the vendor was that much better than
information they provide via hardware.
"Hey, the tester says that the new monitor doesn't work with his video
card, it says 'out of range'"
"Oh, indeed, we broke EDID. Don't worry, we'll fix it on the driver
CD"
OG.
9:51 a.m.
On Sun, 2007-09-02 at 21:59 +0200, Olivier Galibert wrote:
On Sun, Sep 02, 2007 at 02:24:06PM +0200, Matej Cepl wrote:
> Concerning the former, I don't understand how would information
> provided to Windows by the vendor was that much better than
> information they provide via hardware.
"Hey, the tester says that the new monitor doesn't work with his video
card, it says 'out of range'"
"Oh, indeed, we broke EDID. Don't worry, we'll fix it on the driver
CD"
If you can find _any_ driver CD where this happens, I will gladly write
the code to use it.
- ajax
1:54 p.m.
On Sat, 2007-09-01 at 16:03 -0500, Douglas McClendon wrote:
Adam Jackson wrote:
> If I were being cynical, I'd say a large part of the reason they'll be
> moderately successful at this whole 'bulletproof' thing is due to work
> I've already put in to fixing autoconfiguration within X itself, and
> that the press releases are just so much propaganda. Don't get me
> wrong, Fedora sucks at self-publicity, we should do better, but all I
> see in that project is prettier UI and not technical correctness. If
> you do it _right_, you don't ever have to admit failure. Asking for the
> inf file is admitting failure.
I suspect you'll tell me why I'm wrong- But aren't there (a significant
number of) situations where autodetect fails, and in fact due to
hardware limitations can't succeed, but the process of the user
specifying the monitor type, and info, from the driver CD, will cause
success?
Even if those situations account for 1/10,000 users, those are precisely
the cases that need to be covered to market something as "bulletproof".
Now of course, it won't solve the problem of the user getting confused
and using the wrong CD for the monitor...
Yeah, okay, force me to clarify. Grumble.
There are cases where we can't tell what monitor the user has. They're
almost completely described by "either the card can't do DDC, or the
cable is broken". The former is a vanishingly small class of hardware,
voodoo1 basically. The latter happens depressingly often particularly
with projector setups.
In either case, asking for the windows CD won't tell you what you want
to know. It will tell you sync ranges, when what you _want_ to know is
desired resolution and display type (as in, CRT, LCD, beamer, whatever).
Afterwards you can validate that against the sync ranges from the INF
file if you want, but really, either it'll work or it won't, and asking
for the CD won't make it work better.
It's a red herring, is my point. It's a non-feature. It's like going
to buy a Ferrari and the salesman keeps talking about how great the
cupholders are. They might be great, truly exemplary, but they're not
really what you're interested in.
- ajax
2:34 p.m.
On Mon, 2007-09-03 at 14:54 -0400, Adam Jackson wrote:
In either case, asking for the windows CD won't tell you what you
want
to know. It will tell you sync ranges, when what you _want_ to know is
desired resolution and display type (as in, CRT, LCD, beamer, whatever).
Afterwards you can validate that against the sync ranges from the INF
file if you want, but really, either it'll work or it won't, and asking
for the CD won't make it work better.
As someone who's done some work in the embedded space, I can see how
it's possible that the device might return wrong information which is
superseded by information found in driver updates. Firmware can't always
be updated, so if the hardware does return with some error or new
information is deemed important or necessary, that's usually done
through some file update.
What's the objective here? To come up with working ModeLines for the
video card and video display combination? Don't Windows INF files
contain additional information useful for coming up with those ModeLines
that isn't available from the hardware (EDID)? How does Windows
determine the valid resolutions for the same piece of hardware? When X
can't come up with the same resolutions as Windows, is it because of a
difference in computational algorithms? (someone mentioned how X gives
width more importance) Is there no value to be gained from INF files?
So there are four actors here: the monitor which supplies EDID
information, information provided through some external file like the
Windows INF, the user who might be able to make learned configs and the
X server. I'm sure you all agree that the objective is a working
display. Additionally, you might all agree that most, if not all, of the
actions should be between the X server and the hardware, followed by
additional external information (possibly provided as a file by the
manufacturer or a database of information) and finally the user (whose
sole purpose ideally is just to pick the setting which pleases him/her
most).
It seems people have to agree first on what the ideal objectives are and
then discuss the technical aspects for achieving it.
I agree with another poster who puts value to constructive criticism.
May I also suggest that derogatory remarks or character attacks be
lessened? Also, I hope the developers "in the know" will understand that
in this community, some aren't as technically adept as they are but
would still like to understand and learn, and no amount of post
rereading is going to make it clearer IF there are information lacking
or that needs clearing.
--
Richi Plana
2:53 p.m.
Adam Jackson wrote:
On Sat, 2007-09-01 at 16:03 -0500, Douglas McClendon wrote:
> Adam Jackson wrote:
>
>> If I were being cynical, I'd say a large part of the reason they'll be
>> moderately successful at this whole 'bulletproof' thing is due to work
>> I've already put in to fixing autoconfiguration within X itself, and
>> that the press releases are just so much propaganda. Don't get me
>> wrong, Fedora sucks at self-publicity, we should do better, but all I
>> see in that project is prettier UI and not technical correctness. If
>> you do it _right_, you don't ever have to admit failure. Asking for the
>> inf file is admitting failure.
> I suspect you'll tell me why I'm wrong- But aren't there (a significant
> number of) situations where autodetect fails, and in fact due to
> hardware limitations can't succeed, but the process of the user
> specifying the monitor type, and info, from the driver CD, will cause
> success?
>
> Even if those situations account for 1/10,000 users, those are precisely
> the cases that need to be covered to market something as "bulletproof".
>
> Now of course, it won't solve the problem of the user getting confused
> and using the wrong CD for the monitor...
Yeah, okay, force me to clarify. Grumble.
There are cases where we can't tell what monitor the user has. They're
almost completely described by "either the card can't do DDC, or the
cable is broken". The former is a vanishingly small class of hardware,
voodoo1 basically. The latter happens depressingly often particularly
with projector setups.
So, to save you the trouble of rereading all of my posts. Can you
explicitly confirm this (which it sounds like you did, but not in a way
that clearly addressed the point I tried to make half a dozen times last
night).
Repeat after me-
"There is *NEVER* a situation, when the monitor fails to provide correct
information, due to a broken or absent edid implementation, and which at
the same time, sufficient information could be parsed from the .inf that
came on the CD with the monitor, to provide the user, a reasonable
experience requiring no user interaction beyond putting the cd in the
drive". (and at which time, the X driver could not have accomplished
the same thing automatically without the .inf)
If that truly is *NEVER* a possibility, then my main speculative
argument, was wrong.
You make it sound as though monitor .inf files *NEVER* contain available
resolution information. This sounds odd to me. Please verify my
understanding of that as well.
-dmc
In either case, asking for the windows CD won't tell you what you want
to know. It will tell you sync ranges, when what you _want_ to know is
desired resolution and display type (as in, CRT, LCD, beamer, whatever).
Afterwards you can validate that against the sync ranges from the INF
file if you want, but really, either it'll work or it won't, and asking
for the CD won't make it work better.
It's a red herring, is my point. It's a non-feature. It's like going
to buy a Ferrari and the salesman keeps talking about how great the
cupholders are. They might be great, truly exemplary, but they're not
really what you're interested in.
- ajax
3:07 p.m.
I think the onus should be on the other foot.
Unless you are the one doing the work, it is for you to prove that
there is a benefit. Should be rather easy.
("I can prove that dogs exist. I cannot prove that aliens do not" is
probably a bad analogy...)
3:19 p.m.
Naheem Zaffar wrote:
I think the onus should be on the other foot.
Unless you are the one doing the work, it is for you to prove that
there is a benefit. Should be rather easy.
("I can prove that dogs exist. I cannot prove that aliens do not" is
probably a bad analogy...)
Since he is the 'indisputable' X hacker, I am willing to take his word,
that if he has *NEVER* seen such a scenario, that they don't exist.
Perhaps I should have phrased the question - 'You have never seen a
situation', or 'you have never run across a situation'.
Honestly, I think I might have a situation, if I could actually track
down the driver cd for the monitor I have (which I bought from a
surplus, with no driver cd). I.e. my micron ap150t, with current fc7,
comes up as 800x600, when it is a 1024x768 lcd.
My suspicion is that in the .inf file for the monitor, is the
information about the hsync, the vsync, and that it is capable of
1024x768 resolution, which would be all the info needed.
But I admit, suspicions aren't worth anything in this argument.
-dmc
4 p.m.
On Mon, 2007-09-03 at 15:19 -0500, Douglas McClendon wrote:
Honestly, I think I might have a situation, if I could actually track
down the driver cd for the monitor I have (which I bought from a
surplus, with no driver cd). I.e. my micron ap150t, with current fc7,
comes up as 800x600, when it is a 1024x768 lcd.
That would have been a nice example (where the current system doesn't
detect the maximum capabilities properly).
Unfortunately, when I tried searching for the INF files, as well, I
couldn't find any from the official support site
(http://support.mpccorp.com/downloads/driver.html) and the best I could
find was this thread:
http://forums.driverguide.com/showthread.php?t=19355
According to it, no "driver" files exist (no INF files) for WinXP and
for 95/98/Me, the user should just configure it as a "Plug & Play"
monitor. If Windows is getting it right, then it's likely not from an
external input file.
--
Richi Plana
3:27 p.m.
On Mon, 2007-09-03 at 21:07 +0100, Naheem Zaffar wrote:
I think the onus should be on the other foot.
Come on. We're a community here. This isn't supposed to be a debate
where one's only concern is to win the argument. I believe the onus to
reply is on anyone who knows the answer to the question. In case no one
knows the answer for certain, then ideally it would be on all of us who
wants what is best for the project.
Anyway, I thought I'd find out for myself. I went to the ViewSonic
website and downloaded the drivers for WinXP
(http://www.viewsonic.com/support/drivers/download.cfm?key=37). It turns
out that they supply 2 to 3 file per monitor. An optional .cat file
(Catalog file. not sure what that is but it looks like a signature
file), an .icm file (Microsoft ICM Color Profile) and the .inf file.
I took a random INF file and am pasting it in this email. I'm also just
pasting the parts which seem relative to the objective of coming up with
valid Modes and ModeLines:
[VLCDS23412-1.Install] ;VX800
DelReg=DEL_CURRENT_REG
AddReg=VLCDS23412-1.AddReg,1280,DPMS
Copyfiles=VLCDS23412-1.CopyFiles
[DEL_CURRENT_REG]
HKR,MODES
HKR,,MaxResolution
HKR,,DPMS
HKR,,ICMProfile
[1280]
HKR,,MaxResolution,,"1280,1024"
[DPMS]
HKR,,DPMS,,1
[VLCDS23412-1.AddReg] ;VX800
HKR,"MODES\1280,1024",Mode1,,"24-82,56-85,+,+"
HKR,,ICMProfile,0,"VX800.ICM"
[VLCDS23412-1.CopyFiles]
VX800.ICM
I've no idea what these are for, but I'm hoping someone who knows a lot
more can tell me if there's any value here.
Unfortunately, I don't know which monitors / displays don't give correct
EDID information so this is as far as my research could go.
--
Richi Plana
10:01 a.m.
On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote:
Adam Jackson wrote:
> Yeah, okay, force me to clarify. Grumble.
>
> There are cases where we can't tell what monitor the user has. They're
> almost completely described by "either the card can't do DDC, or the
> cable is broken". The former is a vanishingly small class of hardware,
> voodoo1 basically. The latter happens depressingly often particularly
> with projector setups.
So, to save you the trouble of rereading all of my posts. Can you
explicitly confirm this (which it sounds like you did, but not in a way
that clearly addressed the point I tried to make half a dozen times last
night).
Repeat after me-
"There is *NEVER* a situation, when the monitor fails to provide correct
information, due to a broken or absent edid implementation, and which at
the same time, sufficient information could be parsed from the .inf that
came on the CD with the monitor, to provide the user, a reasonable
experience requiring no user interaction beyond putting the cd in the
drive". (and at which time, the X driver could not have accomplished
the same thing automatically without the .inf)
Absent EDID in the sink device never happens anymore. It's a
requirement for Vista certification. I'm fairly sure it was required
for XP cert. It's a requirement for shipping any DVI sink device. It
is _mandatory_.
We can fail to get EDID, either because the cable broke the DDC pins, or
timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or
it's a really old monitor, or there's a crap KVM switch in the middle,
or phase of the moon, or whatever.
I have not found ISOs for every OEM CD for every monitor that ever
shipped. I doubt I ever could. Therefore the following claim is merely
statistical. However, on no OEM CD that I've ever found does the
included INF file - or any other resource intended to be parsed by the
machine - provide the same set of information as the EDID block for the
monitor. It may provide a subset. The only subset I've ever seen is
sync ranges.
I'm not saying I'm happy about that. I would love to see a
counterexample. But it's all the empirical evidence I have.
- ajax
10:25 a.m.
Adam Jackson wrote:
On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote:
> Adam Jackson wrote:
>> Yeah, okay, force me to clarify. Grumble.
>>
>> There are cases where we can't tell what monitor the user has. They're
>> almost completely described by "either the card can't do DDC, or the
>> cable is broken". The former is a vanishingly small class of hardware,
>> voodoo1 basically. The latter happens depressingly often particularly
>> with projector setups.
> So, to save you the trouble of rereading all of my posts. Can you
> explicitly confirm this (which it sounds like you did, but not in a way
> that clearly addressed the point I tried to make half a dozen times last
> night).
>
> Repeat after me-
>
> "There is *NEVER* a situation, when the monitor fails to provide correct
> information, due to a broken or absent edid implementation, and which at
> the same time, sufficient information could be parsed from the .inf that
> came on the CD with the monitor, to provide the user, a reasonable
> experience requiring no user interaction beyond putting the cd in the
> drive". (and at which time, the X driver could not have accomplished
> the same thing automatically without the .inf)
Absent EDID in the sink device never happens anymore. It's a
requirement for Vista certification. I'm fairly sure it was required
for XP cert. It's a requirement for shipping any DVI sink device. It
is _mandatory_.
We can fail to get EDID, either because the cable broke the DDC pins, or
timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or
it's a really old monitor, or there's a crap KVM switch in the middle,
or phase of the moon, or whatever.
I have not found ISOs for every OEM CD for every monitor that ever
shipped. I doubt I ever could. Therefore the following claim is merely
statistical. However, on no OEM CD that I've ever found does the
included INF file - or any other resource intended to be parsed by the
machine - provide the same set of information as the EDID block for the
monitor. It may provide a subset. The only subset I've ever seen is
sync ranges.
I'm not saying I'm happy about that. I would love to see a
counterexample. But it's all the empirical evidence I have.
Just wanted to thank you for writing such informative emails. Everytime
I read one of your emails I learn something about X, and that's awesome.
-denis
4:20 p.m.
Adam Jackson wrote:
On Mon, 2007-09-03 at 14:53 -0500, Douglas McClendon wrote:
> Adam Jackson wrote:
>> Yeah, okay, force me to clarify. Grumble.
>>
>> There are cases where we can't tell what monitor the user has. They're
>> almost completely described by "either the card can't do DDC, or the
>> cable is broken". The former is a vanishingly small class of hardware,
>> voodoo1 basically. The latter happens depressingly often particularly
>> with projector setups.
> So, to save you the trouble of rereading all of my posts. Can you
> explicitly confirm this (which it sounds like you did, but not in a way
> that clearly addressed the point I tried to make half a dozen times last
> night).
>
> Repeat after me-
>
> "There is *NEVER* a situation, when the monitor fails to provide correct
> information, due to a broken or absent edid implementation, and which at
> the same time, sufficient information could be parsed from the .inf that
> came on the CD with the monitor, to provide the user, a reasonable
> experience requiring no user interaction beyond putting the cd in the
> drive". (and at which time, the X driver could not have accomplished
> the same thing automatically without the .inf)
First, thanks for many of these recent educational responses. Something
like cvt I do personally find cool, though clearly it has nothing to do
with the type of situation ubuntu-bulletproof-x is targeting.
Absent EDID in the sink device never happens anymore. It's a
requirement for Vista certification. I'm fairly sure it was required
for XP cert. It's a requirement for shipping any DVI sink device. It
is _mandatory_.
We can fail to get EDID, either because the cable broke the DDC pins, or
timing bugs in the I2C code, or BIOS bugs if we're using VBE DDC, or
it's a really old monitor, or there's a crap KVM switch in the middle,
or phase of the moon, or whatever.
This sounds like an aweful lot of situations. I suspect my micron
apt150t falls into more than one of them (not DVI, not vista certified,
probably not xp certified, 'really old', who knows about about i2c
timing and/or bios bugs...).
I'll save the details of my s-c-d fun yesterday for a bug report, but
suffice it to say that after selecting 'generic 1024x768 lcd panel' and
seeing that in xorg.conf, it decided to start up in 1378x768... Not
reproducibly though.
My point, if I even have one anymore, is that it sounds like the above
(my situation, and what you said), are a multitude of situations where
.inf info might come in useful. But you did clarify below...
I have not found ISOs for every OEM CD for every monitor that ever
shipped. I doubt I ever could. Therefore the following claim is merely
statistical. However, on no OEM CD that I've ever found does the
included INF file - or any other resource intended to be parsed by the
machine - provide the same set of information as the EDID block for the
monitor. It may provide a subset. The only subset I've ever seen is
sync ranges.
From Richi Plana's posted .inf
"
[1280]
HKR,,MaxResolution,,"1280,1024"
"
I'm not saying I'm happy about that. I would love to see a
counterexample. But it's all the empirical evidence I have.
I would truly love to provide a counterexample with my micron ap150t,
but as was pointed out elsewhere in this thread, that is one example
where the .inf truly does not exist on the face of the earth. But if it
did, and had something like the MaxResolution quoted above, that would
be a valid counterexample, right?
-dmc
P.S. I honestly don't care enough about this thread to restore my copy
of vista on my laptop (haven't had winblowz in my home for >6months)
which has a vga-out, to see if windows can do better with that monitor
than F7.
1:15 p.m.
On 8/31/07, Dave Airlie <airlied(a)redhat.com> wrote:
Really if you have to ask the user you've already lost....
The main use this gives is you can let a user try the binary driver, and
if it tanks, you can use the GUI to go back to the open source or vice
versa,
Really though a simple ordering like:
1. Users current xorg.conf
2. No x.org conf - default driver
3. Try another driver in list (like fglrx or radeon)
4. Try vesa.
5. lose.
So you have either a choice to lose, and let the user feel helpless
and out of control, or you give them at least a chance to try
something out. If the user is intelligent, even if he's not
technically oriented, he can then say "I tried the following settings
and they all didn't work."
Not that I'm going to say this is the best implementation either, but
it's better than just a BSOD (Black Screen of Doom).
-Yaakov
1:28 p.m.
Yaakov Nemoy wrote:
> The main use this gives is you can let a user try the binary
driver, and
> if it tanks, you can use the GUI to go back to the open source or vice
> versa,
>
> Really though a simple ordering like:
> 1. Users current xorg.conf
> 2. No x.org conf - default driver
> 3. Try another driver in list (like fglrx or radeon)
> 4. Try vesa.
> 5. lose.
So you have either a choice to lose, and let the user feel helpless
and out of control, or you give them at least a chance to try
something out. If the user is intelligent, even if he's not
technically oriented, he can then say "I tried the following settings
and they all didn't work."
Not that I'm going to say this is the best implementation either, but
it's better than just a BSOD (Black Screen of Doom).
The biggest problem I've seen with X is having to provide modelines for
equipment not included in the stock setup. Is there any way that when
someone computes their own modelines and it comes up working that the
system could automatically ask permission to post the settings to a
central database so others with matching hardware would not have to
repeat the work?
--
Les Mikesell
lesmikesell(a)gmail.com
1:46 p.m.
On 8/31/07, Les Mikesell <lesmikesell(a)gmail.com> wrote:
Yaakov Nemoy wrote:
>> The main use this gives is you can let a user try the binary driver, and
>> if it tanks, you can use the GUI to go back to the open source or vice
>> versa,
>>
>> Really though a simple ordering like:
>> 1. Users current xorg.conf
>> 2. No x.org conf - default driver
>> 3. Try another driver in list (like fglrx or radeon)
>> 4. Try vesa.
>> 5. lose.
>
> So you have either a choice to lose, and let the user feel helpless
> and out of control, or you give them at least a chance to try
> something out. If the user is intelligent, even if he's not
> technically oriented, he can then say "I tried the following settings
> and they all didn't work."
>
> Not that I'm going to say this is the best implementation either, but
> it's better than just a BSOD (Black Screen of Doom).
The biggest problem I've seen with X is having to provide modelines for
equipment not included in the stock setup. Is there any way that when
someone computes their own modelines and it comes up working that the
system could automatically ask permission to post the settings to a
central database so others with matching hardware would not have to
repeat the work?
Sounds like a job for Smolt
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
6083
days inactive
6088
days old
63 comments
21 participants
participants (21)
-
Adam Jackson -
Arthur Pemberton -
Daniel Fitzgibbons -
David Airlie -
David Nielsen -
Denis Leroy -
Dominik 'Rathann' Mierzejewski -
Douglas McClendon -
Jef Spaleta -
Jeroen van Meeuwen -
Les Mikesell -
Matej Cepl -
Naheem Zaffar -
Neal Becker -
Nicolas Mailhot -
Olivier Galibert -
Ray Strode -
Richi Plana -
Sankarshan Mukhopadhyay -
Thorsten Leemhuis -
Yaakov Nemoy