Re: DPI with multiple heads and virtual desktops
On Sun, Aug 24, 2003 at 11:16:23PM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? This is my point exactly. When I raised this issue it was not to elicit a correct solution, but rather to point out that the whole notion of DPI is nonsense WRT Xinerama/MergedFB. I would suggest this as a correct-ish solution: If Xinerama/MergedFB detects that both screens have nearly the same resolution (to within some configurable tolerance) then use the average of the two. Otherwise the user has to specify the DPI to use with the -dpi command line switch or some other mechanism. (Is there a DPI option in the XF86Config file?) It might be nice to be able to specify use DPI from screen foo in the ServerLayout section to simplify the process a bit. There is no DPI option in the XF86Config file, but one could be added. That's true, but we have DisplaySize property in the Monitor section. The -dpi command line option is global, applying to all screens. I see. Is it updated in the Xserver manual page? I have the old version which goes like this: -dpi resolution sets the resolution of the screen, in dots per inch. To be used when the server cannot determine the screen size from the hardware. I don't see how that description is inconsistent with what I said. Maybe knowing how it works influences the way I read the description? David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
On Mon, Aug 25, 2003 at 07:40:40PM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? This is my point exactly. When I raised this issue it was not to elicit a correct solution, but rather to point out that the whole notion of DPI is nonsense WRT Xinerama/MergedFB. I would suggest this as a correct-ish solution: If Xinerama/MergedFB detects that both screens have nearly the same resolution (to within some configurable tolerance) then use the average of the two. Otherwise the user has to specify the DPI to use with the -dpi command line switch or some other mechanism. (Is there a DPI option in the XF86Config file?) It might be nice to be able to specify use DPI from screen foo in the ServerLayout section to simplify the process a bit. There is no DPI option in the XF86Config file, but one could be added. That's true, but we have DisplaySize property in the Monitor section. The -dpi command line option is global, applying to all screens. I see. Is it updated in the Xserver manual page? I have the old version which goes like this: -dpi resolution sets the resolution of the screen, in dots per inch. To be used when the server cannot determine the screen size from the hardware. I don't see how that description is inconsistent with what I said. Maybe knowing how it works influences the way I read the description? Sorry, I didn't imply the inconsistency in your words. I only think that current description could benefit from some more details. In my eyes, it would be worth mentioning that this option will apply to all screens. OK. Also, I believe that it would be good to state that the -dpi option will overwrite the resolution of all screens even in the case when resolution is implicitely defined via Monitor/DisplaySize and Screen/Display/Modes options. If it's the case. I guess we should state somewhere that command line options always override parameters from elsewhere, just as parameters supplied explicitly in the config file override auto-detected values, which in turn override fall-back default values. I'll try to make this clearer in the relevant man pages. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
On Sun, Aug 24, 2003 at 12:16:23PM +0200, Alexander Pohoyda wrote: David Dawes [EMAIL PROTECTED] writes: Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? This is my point exactly. When I raised this issue it was not to elicit a correct solution, but rather to point out that the whole notion of DPI is nonsense WRT Xinerama/MergedFB. I would suggest this as a correct-ish solution: If Xinerama/MergedFB detects that both screens have nearly the same resolution (to within some configurable tolerance) then use the average of the two. Otherwise the user has to specify the DPI to use with the -dpi command line switch or some other mechanism. (Is there a DPI option in the XF86Config file?) It might be nice to be able to specify use DPI from screen foo in the ServerLayout section to simplify the process a bit. There is no DPI option in the XF86Config file, but one could be added. That's true, but we have DisplaySize property in the Monitor section. The -dpi command line option is global, applying to all screens. It is easier to use when you want that result, and especially in the Xinerama case where it may not be possible to derive a unique value for the single screen presented to clients. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
Dr Andrew C Aitchison writes: Are you sure you actually want the problem solved anyway ? We have a laptop with a 125dpi screen and a lecture room projector with about 8dpi. If I were to make it run a two screen desktop, and my slide viewer honoured the true screen DPI, on one screen 12pt letters would be 20 pixels tall, and on the other they would be about one pixel. This illustrates how useless the screen size is to determine the 'felt' DPI ie. the resolution the user really feels. To calculate this value (and that is what should really matter) we have to make a number of assumptions: 1. The user adjusts his display so that he can view it comfortably, that is he places it at a distance to his eyes that he can view the entire screen without head and with very little eye movement. 2. There is a certain horizontal and vertical angle within which objects appear sharp and with sufficient details to the human eye. If we review literature about workplace ergonomy we may find an average value for these vision angles. 3. When we read (from paper) we adjust the paper so that it is at a comfortable viewing distance. If we place it closer to our eyes it will overstrain the muscles that focus the lense if we place it too far away the text will become too hard to read. For all people with normal sight (or using corrective devices to restore normal sight) this distance is approximately the same. There should be more or less agreed upon value in literature also. 4. When we view a document on the computer screen we want it to appear at approximately the same vision angle as we read the same document from paper. Using assumption 2. and 3. we can calculate the size of the vision field at the 'comfortable reading distance': q_h, q_v := horizontal/vertical vision angle d := 'comfortable' reading distance h,v := horizontal/vertical dimension of vision field h = 2 * d * tan(q_h/2) v = 2 * d * tan(q_v/2) From assumption 1 and 4 it is immediately clear that to obtain a roughly equal viewing angle for documents viewed on the computer screen and on paper we need to use these values to determine the DPI. The horizontal/vertical display ratio of a computer screen is approximately 4/3 in most cases. Assuming that h/v 4/3 Therefore the vertical screen size will determine the distance of the screen to the eyes. With: D_h, D_v := horizontal/vertical size of the computer screen we can therefore calculate the 'felt' screen dimensions like: v_s = v h_s = v * D_h / D_v Applications are passed the screen dimensions and the virtual pixel dimensions. Thus we should correct the screen sizes passed to the application: To do this we can either use the physical pixel size used at server startup time or the one that's used at the time the application is started. With: r_h, r_v := physical pixel size r_h_virt, r_v_virt := pixel size of the virtual screen v_s' = v_s * r_v_virt / r_v h_s' = h_s * r_h_virt / r_h These should be the screen dimension values passed in the connection block. So far we have dealt with idnividual screens. The Xinerama case needs to be treated a little differently. The personal preferences of the user may deviate from the 'normed' values of the viewing angles and comfortable reading distance. Furthermore the user may want only a portion of the screen to appear in his 'viewing area'. Since all relationships above are linear a single scaling factor Will suffice to allow the user to adjust things for is personal preferences. XINERAMA Here we must distinguish two uses: 1. The desktop 2. The video wall 1. Desktop == Xinerama knows abbout a single rectangle screen with no holes. It therefore doesn't make much sense to combine screens with different resolutions as the screen will contain unviewable areas. We should also assume that the user uses displays of similar physical dimensions or at least places the displays in a way that he can view them under the same viewing angle. At the same time we assume that the user views an application window on a single screen. To view windows on the other screen the user will move his eyes or head. Therefore the calculated resolution should be the same as the one of a single head. We therefore need to 'rescale' the screen dimensions passed in the connection block: With r_h_virt, r_v_virt := pixel size of the Xinerama virtual screen r_h_virt1, r_v_virt1 := pixel size of the virtual screen of the first head we get: v_s'' = v_s' * r_v_virt / r_v_virt1 h_s'' = h_s' * r_h_virt / r_h_virt1 2. Video Wall = As the viewer is expected to view the entire screen at once the calculation is similar to the single desktop. To calculate the 'felt' horizontal dimension one needs to obtain D_h and D_v. if we assume that identical screens are used with the virtual pixel size equal to the physical size desktops are used we can do: D_h = D_h_1 * r_h_virt1 / r_h_virt D_v = D_v_1
Re: DPI with multiple heads and virtual desktops
Ar an 20ú lá de mí 8, scríobh Dr Andrew C Aitchison : We have a laptop with a 125dpi screen and a lecture room projector with about 8dpi. If I were to make it run a two screen desktop, That's almost the argument Charles Petzold makes for the general crapness in the DPI system in Win32, and it's fallacious. Practically no-one wants to run a two screen desktop in that situation; the laptop screen ends up facing the speaker, and the speaker ends up standing in front of the projection screen. No-one gets to see both screens; no-one wants to. The speaker might like to be able to have private notes available, but she also wants to be sure she knows exactly what her audience is seeing. -- These are the prettiest looking witnesses we have had in a long time. I imagine you are all married. If not, you could be if you wanted to be. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
Dr Andrew C Aitchison wrote: On Wed, 20 Aug 2003, Alex Deucher wrote: this is a semi-fix, but it still does not deal with monitors that have different DPI. Perhaps this is something that needs to be looked at for xfree 5. Almost certainly not before XFree86 v5. Even then I don't think a solution to your problem is actually possible for Xinerama; I don't know whether it would be for MergedFB. Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? This is my point exactly. When I raised this issue it was not to elicit a correct solution, but rather to point out that the whole notion of DPI is nonsense WRT Xinerama/MergedFB. I would suggest this as a correct-ish solution: If Xinerama/MergedFB detects that both screens have nearly the same resolution (to within some configurable tolerance) then use the average of the two. Otherwise the user has to specify the DPI to use with the -dpi command line switch or some other mechanism. (Is there a DPI option in the XF86Config file?) It might be nice to be able to specify use DPI from screen foo in the ServerLayout section to simplify the process a bit. IMO either you want the same DPI on both screens (fake whatever value you want with DisplaySize or X -dpi NN) or you want two non-xinerama heads - display:0.0 and display:0.1, which allows apps on each head to get the right answer for that screen*, and stops the DPI changes which would occur if the window was allowed to move between screens. I agree, but I think that Xinerama/MergedFB could at least be smart enough to either: A. do the right thing if you have two displays with the same DPI or B. throw in the towel when you have two displays with very different DPI. Cheers, -n8 -- -- Nathaniel Gray -- Caltech Computer Science -- -- Mojave Project -- http://mojave.cs.caltech.edu -- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
Alex Deucher wrote:
How is DPI supposed to work if you have a virtual desktop larger than
the current mode? the current code seems to produce the wrong DPI.
xf86SetDpi() has the following code:
if (pScrn-widthmm 0) {
pScrn-xDpi =
(int)((double)pScrn-virtualX * MMPERINCH / pScrn-widthmm);
}
if (pScrn-heightmm 0) {
pScrn-yDpi =
(int)((double)pScrn-virtualY * MMPERINCH / pScrn-heightmm);
}
if you have, for example,
DisplaySize 300 230
and a virtual resolution of say 2048x768 and a mode of 1024x768, the
DPI would get set to 173, 84. which (I think) is wrong. it should be
86, 84 which is what you would get when your mode matches your virtual
resolution. I'm having the same problem with Mergedfb since it uses a
virtual resolution with two viewports looking into it. I could add the
heightmm or widthmm of both heads to make the DPI correct for the
virtual size with respect to the two heads. I'm not sure how xinerama
deals with it. maybe the current behavior is right? I dunno.
Thoughts?
Without actually having looked at this, my preliminary opinion is that
what we do presently is correct. I don't see the mode dimensions
anywhere in the calculation you quoted above.
virtualX and Y can be bigger than the viewport in any case (not just
MergedFB mode). I think the whole DPI system is based on the assumption
that you _see_ the whole (virtual) desktop, ie you're running at the
maximum mode(s on each head). The only thing one has to do is to set
DisplaySize correctly, namely to the over-all size of BOTH heads
(depending on their relative location, of course).
As Aitchison showed in his reply, Xinerama does basically the same as it
just resizes the mmWidth/Height with regard to the second head, although
it does this by calculating some sort of average.
Be it adding the second head's dimension to the mmHeight/Width, be it
calculating an average, both methods are likewise inaccurate if you use
two output devices with different actual DPI values.
But as said, this is my unqualified opinion without looking at it
closer. I'll think about it.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
--- Thomas Winischhofer [EMAIL PROTECTED] wrote:
Alex Deucher wrote:
How is DPI supposed to work if you have a virtual desktop larger
than
the current mode? the current code seems to produce the wrong DPI.
xf86SetDpi() has the following code:
if (pScrn-widthmm 0) {
pScrn-xDpi =
(int)((double)pScrn-virtualX * MMPERINCH /
pScrn-widthmm);
}
if (pScrn-heightmm 0) {
pScrn-yDpi =
(int)((double)pScrn-virtualY * MMPERINCH /
pScrn-heightmm);
}
if you have, for example,
DisplaySize 300 230
and a virtual resolution of say 2048x768 and a mode of 1024x768,
the
DPI would get set to 173, 84. which (I think) is wrong. it should
be
86, 84 which is what you would get when your mode matches your
virtual
resolution. I'm having the same problem with Mergedfb since it
uses a
virtual resolution with two viewports looking into it. I could add
the
heightmm or widthmm of both heads to make the DPI correct for the
virtual size with respect to the two heads. I'm not sure how
xinerama
deals with it. maybe the current behavior is right? I dunno.
Thoughts?
Without actually having looked at this, my preliminary opinion is
that
what we do presently is correct. I don't see the mode dimensions
anywhere in the calculation you quoted above.
Sorry, I just used that mode as an example. It doesn't get used in the
calculation. what I meant to say is when your monitor's aspect ratio
matches your virtual screen's aspect ratio
virtualX and Y can be bigger than the viewport in any case (not just
MergedFB mode). I think the whole DPI system is based on the
assumption
that you _see_ the whole (virtual) desktop, ie you're running at the
maximum mode(s on each head). The only thing one has to do is to set
DisplaySize correctly, namely to the over-all size of BOTH heads
(depending on their relative location, of course).
And that's where the problem is. xf86SetDpi() only works right if the
virtual resolution and the monitor have the same aspect ratio.
As Aitchison showed in his reply, Xinerama does basically the same as
it
just resizes the mmWidth/Height with regard to the second head,
although
it does this by calculating some sort of average.
Be it adding the second head's dimension to the mmHeight/Width, be it
calculating an average, both methods are likewise inaccurate if you
use
two output devices with different actual DPI values.
yup.
But as said, this is my unqualified opinion without looking at it
closer. I'll think about it.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
On Wed, 20 Aug 2003, Alex Deucher wrote: this is a semi-fix, but it still does not deal with monitors that have different DPI. Perhaps this is something that needs to be looked at for xfree 5. Almost certainly not before XFree86 v5. Even then I don't think a solution to your problem is actually possible for Xinerama; I don't know whether it would be for MergedFB. Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? Are you sure you actually want the problem solved anyway ? We have a laptop with a 125dpi screen and a lecture room projector with about 8dpi. If I were to make it run a two screen desktop, and my slide viewer honoured the true screen DPI, on one screen 12pt letters would be 20 pixels tall, and on the other they would be about one pixel. IMO either you want the same DPI on both screens (fake whatever value you want with DisplaySize or X -dpi NN) or you want two non-xinerama heads - display:0.0 and display:0.1, which allows apps on each head to get the right answer for that screen*, and stops the DPI changes which would occur if the window was allowed to move between screens. * Ignoring ctlalt+/- mode changes. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DPI with multiple heads and virtual desktops
On Thu, Aug 21, 2003 at 12:02:27AM +0200, Michel Dänzer wrote: On Wed, 2003-08-20 at 09:02, John Meacham wrote: if only there were an extension allowing windows to be migrated between screens by the window manager [...] FWIW, GTK can migrate between displays as of 2.2, I don't know if or how this works with any given GTK app though. AFAIK there are also other solutions for this, but they might just be hacks. The missing piece is a protocol (ICCCM-style, no server changes involved) to let the WM signal to the app that it should move a window. There's been a proposal on wm-spec-list for this. Havoc ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
