FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-04-2011, 07:53 PM
Felix Miata
 
Default Why EDID is not trustworthy for DPI

Ordinary users don't care about DPI any more than they do about what number
point or pixel size their favorite font size is.

Why can't something akin to
http://people.gnome.org/~federico/news-2007-01.html be employed so that no
one gets initialized or stuck with unsuitable sizes?

Snap the result to a multiple of 4, 6, 12 or 24 so that font steps between
sizes coordinate well with common scalable font behavior, and for those who
desire greater accuracy, offer an advanced opt-out to the snap.

Provide optional inputs for screen width, height and/or diagonal and the
under-the-covers DPI might occasionally turn out to match the display
density, an ideal result for probably most people.

Focus on getting it suitable for single display users before attacking multis.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-04-2011, 08:03 PM
Camilo Mesias
 
Default Why EDID is not trustworthy for DPI

Hi,

On Tue, Oct 4, 2011 at 6:54 PM, Adam Jackson <ajax@redhat.com> wrote:
> I am clearly going to have to explain this one more time, forever.
> Let's see if I can't write it authoritatively once and simply answer
> with a URL from here out. *(As always, use of the second person "you"
> herein is plural, not singular.)

Thanks for the explanation... There is an alternative to endless
explanation - roll out your best effort at a heuristic and let the
crowd contribute to an ever growing set of exceptions.

To play the devil's advocate, I'm asking why the monitor situation is
different from any other bit of hardware. Drivers for mice, touchpads,
wifi, NICs etc all suffer from the same lack of rigorous published
specs / documentation, they are supported in Linux, fallibly, by ever
growing tables of parameters and heuristics.

-Cam
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-04-2011, 08:17 PM
Martin Langhoff
 
Default Why EDID is not trustworthy for DPI

On Tue, Oct 4, 2011 at 4:03 PM, Camilo Mesias <camilo@mesias.co.uk> wrote:
> Thanks for the explanation... There is an alternative to endless
> explanation - roll out your best effort at a heuristic and let the
> crowd contribute to an ever growing set of exceptions.

Well, actually, people complain a lot more than what the code ;-)

> To play the devil's advocate, I'm asking why the monitor situation is
> different from any other bit of hardware.

And he just explained -- fairly well I would say.

On my part, I say thanks Adam -- even being familiar with some of the
vagaries of manufacturing data for general hardware, monitor's EDID
sounds like an extra-deep nightmare.

For fedora users, as others have mentioned, perhaps a UI that lets
users test a couple of possible dpi values might be useful (for those
users so inclined). It does have to cross a good chunk of the stack to
work well, and seems like a lot of work to get right; but the xrandr
improvements are a start.

For distributors -- such as OLPC -- that are know what HW they are
shipping, it is important to be able to override the guesswork and
state /this/ is my dpi. As far as I can see, Daniel has a way to do it
-- in other cases (ie: mozilla's xulrunner) we've had to patch some
versions so that they'd accept a configured dpi.

cheers,


m
--
*martin.langhoff@gmail.com
*martin@laptop.org -- Software Architect - OLPC
*- ask interesting questions
*- don't get distracted with shiny stuff* - working code first
*- http://wiki.laptop.org/go/User:Martinlanghoff
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-04-2011, 08:24 PM
Casey Dahlin
 
Default Why EDID is not trustworthy for DPI

On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote:
> For fedora users, as others have mentioned, perhaps a UI that lets
> users test a couple of possible dpi values might be useful (for those
> users so inclined). It does have to cross a good chunk of the stack to
> work well, and seems like a lot of work to get right; but the xrandr
> improvements are a start.
>

Windows used to have a gui that would show a ruler on your monitor and
say "hold a real ruler up to this and slide the slider until its the
same size." Given what's been said about how windows handles DPI I can
only wonder what it did, but it might be a nice thing to have.

--CJD
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-04-2011, 09:21 PM
Adam Jackson
 
Default Why EDID is not trustworthy for DPI

On Tue, 2011-10-04 at 21:03 +0100, Camilo Mesias wrote:
> Hi,
>
> On Tue, Oct 4, 2011 at 6:54 PM, Adam Jackson <ajax@redhat.com> wrote:
> > I am clearly going to have to explain this one more time, forever.
> > Let's see if I can't write it authoritatively once and simply answer
> > with a URL from here out. (As always, use of the second person "you"
> > herein is plural, not singular.)
>
> Thanks for the explanation... There is an alternative to endless
> explanation - roll out your best effort at a heuristic and let the
> crowd contribute to an ever growing set of exceptions.

I think you missed the part where I said I already had done so, that
you're already running them, and that I take patches.

I think building the giant database for DPI is a losing battle, and I
don't intend to work on it myself. The bright line for the kernel's
current quirks list has so far been that we take quirks for fixing mode
setup, only. Ancillary data like physical size just isn't something the
kernel needs to know.

But if people do insist on it, there's some points of implementation
that really should be considered, and I'm happy to discuss them.
Overriding EDID is a subtle problem once you get past wanting to make
just one permanently-connected display work on one machine. If the
future being designed looks like "play with this complicated expert tool
until it works for you" then that's not really finished solving the
problem. The next person who uses a sufficiently similar monitor with
the same set of EDID problems should never have to touch that tool.

How people use that information is entirely not my concern. I have an
opinion and it's probably wrong in some cases and I am neither
advocating nor defending any such choices here. I'm just here to tell
you that the hardware _is_ out to get you, and that the current
behaviour is in fact a considered choice and not simply willful malice.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 02:05 AM
Adam Williamson
 
Default Why EDID is not trustworthy for DPI

On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote:

> I'm going to limit myself to observing that "greatly" is a matter of
> opinion, and that in order to be really useful you'd need some way of
> communicating "I punted" to the desktop.
>
> Beyond that, sure, pick a heuristic, accept that it's going to be
> insufficient for someone, and then sit back and wait to get
> second-guessed on it over and over.

All this is interesting, but it basically consists of a long list of
reasons why the EDID info isn't always correct.

96dpi, however, is almost *never* correct, is it? So just taking a
hardcoded number that Microsoft happened to pick a decade ago is hardly
improving matters.

It still seems to me that taking the EDID number if it seems reasonably
plausible and falling back to 96dpi otherwise is likely a better option.

Your examples lean a lot on TVs and projectors, but are those really the
key use cases we have to consider? What about laptops and especially
tablets, whose resolutions are gradually moving upwards (in the laptop
case despite the underlying software problems, in the tablet case
because the underlying software doesn't have such a problem)? Is it
really a great idea, for instance, if we put Fedora 17 on a 1024x600, 7"
tablet and it comes up with zonking huge fonts all over the place?

I think it's worth considering that, even though Microsoft's crappiness
with resolution independence has probably hindered the market
artificially for a while, the 96dpi number which comes from the
capabilities of CRT tubes circa 1995 bears increasingly little
resemblance to the capabilities of modern displays, and assuming we can
just keep hardcoding 96dpi and monitor technology will remain
artificially retarded forever is likely not a great thing to do.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 02:07 AM
Adam Williamson
 
Default Why EDID is not trustworthy for DPI

On Tue, 2011-10-04 at 19:05 -0700, Adam Williamson wrote:

> Is it
> really a great idea, for instance, if we put Fedora 17 on a 1024x600, 7"
> tablet and it comes up with zonking huge fonts all over the place?

Er - s/zonking huge/ridiculously tiny/, of course.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 02:08 AM
Adam Williamson
 
Default Why EDID is not trustworthy for DPI

On Tue, 2011-10-04 at 16:24 -0400, Casey Dahlin wrote:
> On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote:
> > For fedora users, as others have mentioned, perhaps a UI that lets
> > users test a couple of possible dpi values might be useful (for those
> > users so inclined). It does have to cross a good chunk of the stack to
> > work well, and seems like a lot of work to get right; but the xrandr
> > improvements are a start.

> Windows used to have a gui that would show a ruler on your monitor and
> say "hold a real ruler up to this and slide the slider until its the
> same size." Given what's been said about how windows handles DPI I can
> only wonder what it did, but it might be a nice thing to have.

I think it was more some specific app that did that, wasn't it? I'm
almost sure it was either Paint Shop Pro or the GIMP, because obviously,
actual physical accuracy is quite important there. Otherwise it was
something like Office. It was definitely some specific app where WYSIWYG
was important, not an OS.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 12:34 PM
Jeff MacDonald
 
Default Why EDID is not trustworthy for DPI

On Tuesday, October 04, 2011 10:08:33 PM Adam Williamson wrote:
> > Windows used to have a gui that would show a ruler on your monitor and
> > say "hold a real ruler up to this and slide the slider until its the
> > same size." Given what's been said about how windows handles DPI I can
> > only wonder what it did, but it might be a nice thing to have.
>
> I think it was more some specific app that did that, wasn't it? I'm
> almost sure it was either Paint Shop Pro or the GIMP, because obviously,
> actual physical accuracy is quite important there. Otherwise it was
> something like Office. It was definitely some specific app where WYSIWYG
> was important, not an OS.

It makes sense to do that when configuring a desktop environment like Gnome or
KDE.

Regards,
J
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 02:30 PM
Adam Jackson
 
Default Why EDID is not trustworthy for DPI

On Tue, 2011-10-04 at 19:05 -0700, Adam Williamson wrote:

> 96dpi, however, is almost *never* correct, is it? So just taking a
> hardcoded number that Microsoft happened to pick a decade ago is hardly
> improving matters.

The X default used to be 72dpi. Maybe it'll be something else in the
future, and then I can get bitched at more for having changed it yet
again by people still using a fundamentally unreliable API.

> It still seems to me that taking the EDID number if it seems reasonably
> plausible and falling back to 96dpi otherwise is likely a better option.

I reiterate: X gives you the actual sizes (as best as we can guess) on
the RANDR outputs. The global "size" that we default to 96dpi is broken
to rely on in any event, because X simply has no mechanism for updating
it besides reconnecting to the display.

We could add a request to re-fetch the connection handshake block, but
if you're going to update all your apps to use that request, you might
as well update all your apps to use the existing RANDR's geometry
information instead.

If the UI wants to be sensitive to DPI, then do me the favor of using
the DPI numbers that map 1:1 to actual monitors, instead of a single
number that can never be an accurate reflection of reality.

> Your examples lean a lot on TVs and projectors, but are those really the
> key use cases we have to consider? What about laptops and especially
> tablets, whose resolutions are gradually moving upwards (in the laptop
> case despite the underlying software problems, in the tablet case
> because the underlying software doesn't have such a problem)? Is it
> really a great idea, for instance, if we put Fedora 17 on a 1024x600, 7"
> tablet and it comes up with zonking huge fonts all over the place?

I'm going to not mention the traditional monitors I've seen with bad
EDID. I'm going to not mention the laptops I've seen that report 0x0
physical size, or something non-zero and fictitious. I'm going to not
mention the laptops where you simply don't get EDID, you get some subset
buried in the video ROM, and you get to hope that it might have physical
size encoded in it. I'm going to not mention that DPI is only
approximately what you want anyway, and that you actually need to know
dots per unit arc, which is a function of both display size and view
distance.

I'm going to simply quote myself from another message in this thread:
How people use this information is entirely not my concern. My job is
to get the pixels on the screen; it might be to try valiantly to tell
you how big they are; it is not to decide if they're big enough.

> I think it's worth considering that, even though Microsoft's crappiness
> with resolution independence has probably hindered the market
> artificially for a while, the 96dpi number which comes from the
> capabilities of CRT tubes circa 1995 bears increasingly little
> resemblance to the capabilities of modern displays, and assuming we can
> just keep hardcoding 96dpi and monitor technology will remain
> artificially retarded forever is likely not a great thing to do.

I don't believe that was a position I was defending.

I would caution you against thinking that there's some DPI revolution
right around the corner. That's the same fallacy that rages against the
TV industry for "stalling" at 1080p. Linear increases in DPI are
quadratic increases in link bandwidth, and maxed-out single-link DVI
(the source of the 1080p limit) is already a higher symbol rate than
gigabit ethernet.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org