[Fwd: xorg Digest, Vol 36, Issue 25]
Regina
regina.apel at gmx.de
Thu Jul 3 02:51:47 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 25
Datum: Thu, 03 Jul 2008 02:32:49 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. [Fwd: xorg Digest, Vol 35, Issue 127] (Regina)
2. [Fwd: xorg Digest, Vol 35, Issue 128] (Regina)
----------------------------------------------------------------------
Message: 1
Date: Thu, 03 Jul 2008 11:32:06 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 35, Issue 127]
To: xorg at lists.freedesktop.org
Message-ID: <486C9C96.4040202 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 35, Issue 127
Datum: Mon, 30 Jun 2008 17:22:20 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. the OLPC XO grab button (triggering mouse scrolling using a
keypress) (Erik Garrison)
2. [ANNOUNCE] xf86-video-nv 2.1.10 (Aaron Plattner)
3. Re: Resolution indpendence (Steven J Newbury)
4. Re: Max resolution of Intel Graphics Chipsets (Erwin Rol)
5. Re: Further notes on 7.4 (Brian Paul)
6. Re: Tracing Xserver (Mohan Parthasarathy)
7. Re: Resolution indpendence (James Cloos)
8. Re: Resolution indpendence (Felix Miata)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2008 19:35:16 -0400
From: Erik Garrison <erik at laptop.org>
Subject: the OLPC XO grab button (triggering mouse scrolling using a
keypress)
To: xorg at lists.freedesktop.org
Message-ID: <20080630233516.GE10421 at eggs>
Content-Type: text/plain; charset=us-ascii
Xorg-land,
I'm working on implementing a feature for the OLPC XO-1 laptop
(http://dev.laptop.org/ticket/447).
The keyboard has two buttons which are marked with a hand. The
interested may see a schematic at
http://wiki.laptop.org/go/OLPC_Keyboard_layouts. It was intended at
design time that pressing either of these buttons (Super_L and Super_R)
and simultaneously moving the mouse would trigger x and y scrolling in
X11 applications.
I'm curious if anyone knows of ways in which similar functionality has
been implemented elsewhere. In general I'd like some advice about the
best place to implement this feature.
Thanks in advance,
Erik
------------------------------
Message: 2
Date: Mon, 30 Jun 2008 16:41:42 -0700
From: Aaron Plattner <aplattner at nvidia.com>
Subject: [ANNOUNCE] xf86-video-nv 2.1.10
To: xorg at lists.freedesktop.org, xorg-announce at lists.freedesktop.org
Message-ID: <20080630234142.GA31916 at soprano.nvidia.com>
Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This release adds chip names for the GeForce 9 mobile chips and the GeForce GTX
GPUs. It also adds code to read DDC-based EDIDs for LVDS panels that have such
a thing.
- -- Aaron
Aaron Plattner (9):
GeForce 9 mobile chips.
GeForce GTX 280 and 260 chip names.
Replace copyright notices with stock MIT X11 boilerplate.
Add new chips to the man page and fix capitalization of "Quadro".
Add a note that MODE_PANEL really means "larger than BIOS-programmed panel size".
G80: Handle extended I2C ports and LVDS panels with DDC-based EDIDs.
Fix build by using CARD32 instead of uint32_t, like we do everywhere else.
More G8x chips.
Bump to 2.1.10.
git tag: nv-2.1.10
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.10.tar.bz2
MD5: bbee6df3e66d31a7da1afda59b40777d xf86-video-nv-2.1.10.tar.bz2
SHA1: 03545be9634a043b68438dae2a3266c41af60e7e xf86-video-nv-2.1.10.tar.bz2
http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.10.tar.gz
MD5: 894fea928c2e2f548c28b9ff413a6cc6 xf86-video-nv-2.1.10.tar.gz
SHA1: 7d412f87a4a2ee3d62719b71465fb62912aba5e1 xf86-video-nv-2.1.10.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iQEcBAEBAgAGBQJIaW82AAoJEHYgpP6LHaLQgc8H/0T7D37kqoGBpfxt7G2+oP+i
pqBS6GqGhClabnxqfu7HG1BxoagB5stJ70+87M/IHO+JKyczgizQw3/KUkA25TgM
Pv+4DrXOB5KpB/tBqfaXEb2JAZmjAiFPLQdGI39G9XiX5z83oMYxvmozhxFSmtE4
IfEcxSHu/v1W7W1KOdadq1Bz6yoE2CFyNR3n8DVg2rMgu9cIdvwDBBFSsLewehYB
6czQ5065HAHONtfLWV+zPCygzeUClO0iwfQuLOVWArPhW05p2cF0HE1KAs/zQBc/
FRCxu1Kew2gcVRJ+0b74HK7kxzAxO07DpfTxukSqTtC7YG7TAR+vx9OXKCXfeEE=
=eMKb
-----END PGP SIGNATURE-----
------------------------------
Message: 3
Date: Tue, 01 Jul 2008 00:54:01 +0100
From: Steven J Newbury <steve at snewbury.org.uk>
Subject: Re: Resolution indpendence
To: Glynn Clements <glynn at gclements.plus.com>
Cc: xorg at lists.freedesktop.org
Message-ID:
<1214870043.15478.71.camel at infinity.southview.snewbury.org.uk>
Content-Type: text/plain
On Tue, 2008-07-01 at 00:25 +0100, Glynn Clements wrote:
> Steven J Newbury wrote:
> >
> > Going forward with SVG icons it's not going to be a problem. A "best" (user
> > preference) solution can be applied for "legacy" software if necessary.
> > Notice that Vista deals with all legacy applications by using the hardware
> > scaler of the graphics card to provide 96dpi compatiblity.
>
> This only really works for larger icons. If you have a 48x48 icon,
> anti-aliased re-scaling is likely to give adequate results at "large"
> icon sizes. When you get down to the 16x16 icons used in the file
> manager in list/detail view, it really needs to be hand-tuned to avoid
> just being a coloured blob.
If icon sizes need be that small then, absolutely, a hand-tuned bitmap
is probably the only way to go. On a high DPI display such icons are
larger than 16x16 though. Scaling down to very low DPI screens may be
"good enough", how bad do you find the current SVG icon themes to be in
such cases?
> I don't much like DWIM either, but then I'm a programmer. I'm used to
> analysing exactly what I'm trying to achieve, and to figuring out how
> to achieve it. User's often don't know in concrete terms what they
> want, but they know if it's not right and, to an extent, why.
>
> AI won't make it any better. If you want predictability, true AI will
> make it even worse.
>
> Really, it depends upon the situation. DWIM is a bad idea for discrete
> choices, and where getting it right matters. OTOH, where you have a
> continuous range, and you only need to be close enough, it can save
> the user from wasting time micromanaging stuff they don't particularly
> care about.
We have some common ground here.
> >
> > I'm not convinced.
>
> I don't doubt it.
>
> > You'll have to try harder.
>
> What's the point? It's not as if any amount of argument is going to
> convince you. "For your friends, no explanation is necessary; for your
> enemies, none will suffice".
Yes, I'm sorry how that came across, I did mean it in good humour.
------------------------------
Message: 4
Date: Tue, 01 Jul 2008 01:55:27 +0200
From: Erwin Rol <mailinglists at erwinrol.com>
Subject: Re: Max resolution of Intel Graphics Chipsets
To: Tomas Carnecky <tom at dbservice.com>
Cc: xorg <xorg at lists.freedesktop.org>
Message-ID: <1214870127.20839.62.camel at eir.home.erwinrol.com>
Content-Type: text/plain; charset=UTF-8
On Tue, 2008-07-01 at 01:26 +0200, Tomas Carnecky wrote:
> Erwin Rol wrote:
> > Hello all,
> >
> > I am looking for a solution where I can connect two TFT's of 1440x900,
> > and display different images on those TFT's.
> >
> > Most Intel chipsets support two independent outputs, but it seems that
> > the internal framebuffer is the limiting factor here. I would need
> > 2880x900 or 1440x1800 (the layout is not important).
> >
> > For example, do I understand correct that for example the Intel 915
> > chipset does support two outputs of 1440x900 (or even larger), but that
> > the internal framebuffer only can be 2048x1536?
> >
> > I checked several Intel chipsets and they all seem to be "limited" to
> > 2048x1536. Are there Intel chipsets that can do for example 2048x2048,
> > so it can fit a 1440x1800 resolution?
>
> $ xrandr
> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x 1440
> ...
>
Weird the datasheet mentions a maximum resolution of ;
- Supports flat panels up to 2048x1536 @ 60 Hz or digital CRT/HDTV at
1920x1080 @ 85 Hz
?
> This is on a i965 chip. But I'm sure the vertical resolution could go
> much above the 1440. In any way, 2048x2048 is only the limitation of the
> 3D engine, if you don't need OpenGL (compiz, games etc), the limit is
> much higher. And i965 has the 3D limit at 8192x8192, only older chips
> have the above mentioned 2048x2048.
>
> tom
Is the some list somewhere with what the Intel Graphic chips can and can
not do ? Like maximum 2D/3D/video-overlay resolution, maximum
framebuffer size, etc. ?
Tom thanks for the info/help.
- Erwin
------------------------------
Message: 5
Date: Mon, 30 Jun 2008 18:00:49 -0600
From: Brian Paul <brian.paul at tungstengraphics.com>
Subject: Re: Further notes on 7.4
To: Daniel Stone <daniel at fooishbar.org>, xorg at lists.freedesktop.org
Message-ID: <486973B1.3090008 at tungstengraphics.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Daniel Stone wrote:
> On Mon, Jun 30, 2008 at 04:11:52PM -0700, Dan Nicholson wrote:
>> On Mon, Jun 30, 2008 at 3:33 PM, Daniel Stone <daniel at fooishbar.org> wrote:
>>> I think all the reasons I raised in the core fonts mail still apply
>>> here. People bootstrapping from scratch have a hard life as it is, so I
>>> think it makes sense to ease the load on our core audience of people
>>> building on existing distributions, and just include one more
>>> documentation point for people who already have to follow a lot of very
>>> sketchy documentation.
>> Yeah, I suppose that you're mostly right about who the people are who
>> are building X and that they can keep using the X apps on their
>> distro. What I'd like to see, though, is a clear data point that says
>> "here are the tarballs for the core X installation, but you can get
>> all the extra/legacy/whatever stuff here (link to
>> releases/individual)". It sucks when something changes and the only
>> notice is a message buried in mailing list archives.
>
> Please, I wouldn't want anyone to think I'm against them writing
> quality, easily-found documentation on our wiki. :)
>
>>> Can Mesa package this then, preferably with the rest of its build system
>>> (i.e. in its tarball)? All yours, krh's and George's good work into
>>> uncoupling our build systems thus far has been brilliant, thanks. :)
>> If makedepend was a single C file, I'd feel more comfortable
>> shoehorning it into mesa. But, you can certainly make GCC do the exact
>> same thing with -M -MF. I don't know about other compilers, though,
>> which is the hangup.
I don't recall other C compilers having a dependency generator option
like gcc.
> I dunno. Either way, it just seems really strange for Mesa's build to
> depend on something that only we provide, and even then it's very
> undocumented.
I've found makedepend on (almost?) every flavor of unix system I've ever
used (Sun, IRIX, AIX, Ultrix, BSD, HP-UX, Stellix(!), etc). There's a
man page for it, btw.
> Surely, if only one external project uses it for their
> own home-grown buildsystem, it's better for them to maintain that in
> there along with mklib and friends, and that way they can control it if
> they need to change it as well?
I bet there's other apps out there that still use makedepend, esp. in
the technical graphics/sci-vis circles. A lot of those apps are old but
are still used every day.
I was using it for many years (early 90s) before I learned that it was
part of X and not just another unix devel tool, like cc.
As long as the distros still include makedepend with the other
development tools, I guess I don't care what X.org does.
If people start reporting that Mesa won't build because makedepend is
absent, I guess I'll pull it into Mesa. But I have a feeling that Mesa
users won't be the only ones complaining.
-Brian
------------------------------
Message: 6
Date: Mon, 30 Jun 2008 17:01:12 -0700
From: "Mohan Parthasarathy" <suruti94 at gmail.com>
Subject: Re: Tracing Xserver
To: xorg at lists.freedesktop.org
Message-ID:
<89dd3da60806301701j7a75ecebxd3677544ecd3c690 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Curious, is this possible ?
thanks
mohan
On Sun, Jun 29, 2008 at 6:24 PM, Mohan Parthasarathy <suruti94 at gmail.com>
wrote:
> Hi,
>
> Is there a way to trace the functioning of Xserver possibly at different
> levels like Terse, Verbose, some
> specific subsystems like DRI, EXA etc. Besides being a useful debugging
> tool, it would also be useful
> to understand different parts of the code interact.
>
> thanks
> -mohan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xorg/attachments/20080630/244b621b/attachment.html
------------------------------
Message: 7
Date: Mon, 30 Jun 2008 20:15:05 -0400
From: James Cloos <cloos at jhcloos.com>
Subject: Re: Resolution indpendence
To: Glynn Clements <glynn at gclements.plus.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <m3skuuzcgv.fsf at lugabout.jhcloos.org>
Content-Type: text/plain; charset=utf-8
>>>>> "Glynn" == Glynn Clements <glynn at gclements.plus.com> writes:
Glynn> And what happens when you log into a single account from multiple
Glynn> X terminals?
That is what separate dpy- and host- specific settings are for.
Xrm handles that perfectly well.
If gtk, qt, et al don?t, that is a bug there.
I haven?t had the opportunity to use a single $HOME from different X
boxen in quite a while. A decade, in fact. And I haven?t had much need
for X over ssh either. Tried it over the years, but never had a good
use case for it.
Maybe with dbus/tcp gconf can Do The Right Thing in such cases?
Or maybe not?
But the general concept of specifying dpi and base font size per dpy,
and basing UI on text extents at that size, is sound. The implmentation
may be only partially there, but that can be fixed.
-JimC
--
James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
------------------------------
Message: 8
Date: Mon, 30 Jun 2008 20:22:42 -0400
From: Felix Miata <mrmazda at ij.net>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <486978D2.7030109 at ij.net>
Content-Type: text/plain; charset=ISO-8859-1
On 2008/07/01 00:25 (GMT+0100) Glynn Clements apparently typed:
> Windows' icon sizes are: 16x16, 24x24, 32x32, 48x48. The first two are
> "small" icons for use in "list" and "detail" views, the last two are
> "large" icons for "icon" view, desktop, start menu etc. In each case,
> the larger version is 50% larger than the smaller version, whereas the
> difference between 1024x768 and 1280x960 is 25%. It's not like fonts,
> where they typically provide bitmaps at 2pt increments.
Sounds to me like you're using the same bogus math as typesetters and web
deeziners use. 8px is not half the size of 16px - it's 25%, length times
width. Size is area, not one single dimension. A 1600x1200 display has 4
times as many logical px (1,920,000) as an 800x600 display (480,000). Thus, a
48x48 icon has 2304px, 2.25 times the 1024px of a 32x32 icon; 4 times as many
as a 24x24 (576).
> The 96 dpi figure was just an arbitrary value, chosen so that various
> common point sizes (6, 8, 12, 16) would work out to an integer number
> of pixels.
It's arbitrary all right, but not necessarily for the reason you claim. e.g.
at 96 DPI:
6pt = 8.000px^~1.5 (not enough px per character box for all complete
character sets to be rendered intelligibly)
8pt = 10.667px^~1.5
10pt = 13.333px^~1.5
12pt = 16.000px^~1.5
16pt = 21.333px^~1.5
The reason anyone else uses it is because M$ uses/used it, and the reason for
that misfortunate legacy is explained on:
http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx
--
"Where were you when I laid the earth's
foundation?" Matthew 7:12 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 35, Issue 127
*************************************
------------------------------
Message: 2
Date: Thu, 03 Jul 2008 11:32:45 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 35, Issue 128]
To: xorg at lists.freedesktop.org
Message-ID: <486C9CBD.5020107 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 35, Issue 128
Datum: Mon, 30 Jun 2008 19:38:26 -0700
Von: xorg-request at lists.freedesktop.org
Antwort an: xorg at lists.freedesktop.org
An: xorg at lists.freedesktop.org
Send xorg mailing list submissions to
xorg at lists.freedesktop.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freedesktop.org/mailman/listinfo/xorg
or, via email, send a message with subject or body 'help' to
xorg-request at lists.freedesktop.org
You can reach the person managing the list at
xorg-owner at lists.freedesktop.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of xorg digest..."
Today's Topics:
1. Re: Further notes on 7.4 (Stuart Kreitman)
2. Re: Resolution indpendence (Glynn Clements)
3. Re: Max resolution of Intel Graphics Chipsets (Roland Scheidegger)
4. Re: Resolution indpendence (Glynn Clements)
5. Re: Resolution indpendence (David De La Harpe Golden)
6. Constant DPI regardless of resolution (Nikos Chantziaras)
7. Re: Further notes on 7.4 (Alan Coopersmith)
8. Re: Resolution indpendence (Felix Miata)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2008 17:54:35 -0700
From: Stuart Kreitman <Stuart.Kreitman at Sun.COM>
Subject: Re: Further notes on 7.4
To: Daniel Stone <daniel at fooishbar.org>, Adam Jackson <ajax at nwnk.net>,
xorg at lists.freedesktop.org
Message-ID: <4869804B.7060108 at sun.com>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
We built it and we use(d?) it in 2 projects. I'm asking around to see
if we still have consumers
of it, but at least one principal guy is on vacation atm.
Stuart K.
Daniel Stone wrote:
> On Mon, Jun 30, 2008 at 02:54:50PM -0400, Adam Jackson wrote:
>
>> In the same vein, I suspect XEvIE will either go away or be much changed
>> by 7.5.
>>
>
> If anyone still wants it around, they're going to have to make it work
> _properly_ with the new stuff, otherwise it's failing to exist.
>
> Cheers,
> Daniel
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
------------------------------
Message: 2
Date: Tue, 1 Jul 2008 01:59:48 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <18537.33156.846108.213669 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Steven J Newbury wrote:
> > > Going forward with SVG icons it's not going to be a problem. A "best" (user
> > > preference) solution can be applied for "legacy" software if necessary.
> > > Notice that Vista deals with all legacy applications by using the hardware
> > > scaler of the graphics card to provide 96dpi compatiblity.
> >
> > This only really works for larger icons. If you have a 48x48 icon,
> > anti-aliased re-scaling is likely to give adequate results at "large"
> > icon sizes. When you get down to the 16x16 icons used in the file
> > manager in list/detail view, it really needs to be hand-tuned to avoid
> > just being a coloured blob.
>
> If icon sizes need be that small then, absolutely, a hand-tuned bitmap
> is probably the only way to go. On a high DPI display such icons are
> larger than 16x16 though. Scaling down to very low DPI screens may be
> "good enough", how bad do you find the current SVG icon themes to be in
> such cases?
Which icons are SVG?
I don't use Gnome or KDE, or a graphical file manager, so about the
only icons I normally see are the stock OK/Cancel/Open/Save etc icons
in the few GTK+ programs which I use.
Mostly, I find that most GTK+ programs oversize everything (icons,
fonts, etc) by default (even after they've been told that the 125 dpi
screen is actually 75 dpi). I find XP's defaults on a 125 dpi screen
(i.e. tiny) to be adequate for normal use (desktop, file manager,
etc), although any heavy-duty text editing is done in XEmacs on Linux
(typically via Xming on the XP box, which needs its own monitor, and I
need desk space more than the Linux box needs a separate monitor).
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 3
Date: Tue, 01 Jul 2008 03:05:31 +0200
From: Roland Scheidegger <sroland at tungstengraphics.com>
Subject: Re: Max resolution of Intel Graphics Chipsets
To: Erwin Rol <mailinglists at erwinrol.com>
Cc: xorg <xorg at lists.freedesktop.org>
Message-ID: <486982DB.2070601 at tungstengraphics.com>
Content-Type: text/plain; charset=UTF-8
On 01.07.2008 01:55, Erwin Rol wrote:
> On Tue, 2008-07-01 at 01:26 +0200, Tomas Carnecky wrote:
>> Erwin Rol wrote:
>>> Hello all,
>>>
>>> I am looking for a solution where I can connect two TFT's of
>>> 1440x900, and display different images on those TFT's.
>>>
>>> Most Intel chipsets support two independent outputs, but it seems
>>> that the internal framebuffer is the limiting factor here. I
>>> would need 2880x900 or 1440x1800 (the layout is not important).
>>>
>>> For example, do I understand correct that for example the Intel
>>> 915 chipset does support two outputs of 1440x900 (or even
>>> larger), but that the internal framebuffer only can be 2048x1536?
>>>
>>>
>>> I checked several Intel chipsets and they all seem to be
>>> "limited" to 2048x1536. Are there Intel chipsets that can do for
>>> example 2048x2048, so it can fit a 1440x1800 resolution?
>> $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1200, maximum
>> 4096 x 1440 ...
>>
>
> Weird the datasheet mentions a maximum resolution of ; - Supports
> flat panels up to 2048x1536 @ 60 Hz or digital CRT/HDTV at 1920x1080
> @ 85 Hz
That's not really "framebuffer" size just what the ramdac (in case of
analog) or single-link tmds is capable of.
> ?
>> This is on a i965 chip. But I'm sure the vertical resolution could
>> go much above the 1440. In any way, 2048x2048 is only the
>> limitation of the 3D engine, if you don't need OpenGL (compiz,
>> games etc), the limit is much higher. And i965 has the 3D limit at
>> 8192x8192, only older chips have the above mentioned 2048x2048.
>>
>> tom
>
> Is the some list somewhere with what the Intel Graphic chips can and
> can not do ? Like maximum 2D/3D/video-overlay resolution, maximum
> framebuffer size, etc. ?
Older (and some not so old) intel chips (everything up to gen 3.5, i.e.
not gen4 (i965) based can do 2kx2k for 3d (both textures and drawing
rectangle), and gen4 can do 8kx8k (textures and drawing rect). According
to the comments in i830_exa.c all these chips can do 2d operations to
larger resolutions than you'd care (32kx64k - I think you had some
trouble allocating enough ram for this :-)).
Textured video source size is obviously limited to what the 3d texture
size is (but driver limited to 2048x2048), overlay source video size
would be 2048x2048 (i915 and newer) but driver limits this to 1920x1088
due to allocation problems.
Roland
------------------------------
Message: 4
Date: Tue, 1 Jul 2008 02:35:27 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
Cc: xorg at lists.freedesktop.org
Message-ID: <18537.35295.302792.141261 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Felix Miata wrote:
> > Windows' icon sizes are: 16x16, 24x24, 32x32, 48x48. The first two are
> > "small" icons for use in "list" and "detail" views, the last two are
> > "large" icons for "icon" view, desktop, start menu etc. In each case,
> > the larger version is 50% larger than the smaller version, whereas the
> > difference between 1024x768 and 1280x960 is 25%. It's not like fonts,
> > where they typically provide bitmaps at 2pt increments.
>
> Sounds to me like you're using the same bogus math as typesetters and web
> deeziners use. 8px is not half the size of 16px - it's 25%, length times
> width. Size is area, not one single dimension. A 1600x1200 display has 4
> times as many logical px (1,920,000) as an 800x600 display (480,000). Thus, a
> 48x48 icon has 2304px, 2.25 times the 1024px of a 32x32 icon; 4 times as many
> as a 24x24 (576).
I think you missed my point, because using areas only makes the issue
more pronounced.
My point is that you need small enough increments that you can always
get roughly the size that you want, rather than being stuck with a
choice between definitely too large or definitely too small.
With fonts, you get that choice. But the interval between the
available icon sizes is much larger.
> > The 96 dpi figure was just an arbitrary value, chosen so that various
> > common point sizes (6, 8, 12, 16) would work out to an integer number
> > of pixels.
>
> It's arbitrary all right, but not necessarily for the reason you claim. e.g.
> at 96 DPI:
>
> 6pt = 8.000px^~1.5 (not enough px per character box for all complete
> character sets to be rendered intelligibly)
> 8pt = 10.667px^~1.5
> 10pt = 13.333px^~1.5
> 12pt = 16.000px^~1.5
> 16pt = 21.333px^~1.5
I have no idea what you're getting at here.
> The reason anyone else uses it is because M$ uses/used it, and the reason for
> that misfortunate legacy is explained on:
> http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx
That's interesting, but it doesn't really have any bearing on the
notion of resolution independence.
So long as display resolutions remain low enough that you have UI
elements which are only a few pixels in size, the fact that you
ultimately have to rasterise whole pixels means that you can't just
operate entirely in physical units, in the same way that you can with
a 300+dpi laser printer.
Well, you *can*, but the artifacts are going to look a lot worse.
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 5
Date: Tue, 01 Jul 2008 02:36:19 +0100
From: David De La Harpe Golden <david.delaharpe.golden at gmail.com>
Subject: Re: Resolution indpendence
To: Steven J Newbury <steve at snewbury.org.uk>
Cc: Glynn Clements <glynn at gclements.plus.com>,
xorg at lists.freedesktop.org
Message-ID: <48698A13.7030207 at googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1
Steven J Newbury wrote:
> If icon sizes need be that small then, absolutely, a hand-tuned bitmap
> is probably the only way to go. On a high DPI display such icons are
> larger than 16x16 though. Scaling down to very low DPI screens may be
> "good enough"
I'd say that would depend on the how "busy" the vector icon is and the
quality of the renderer. It's certainly _possible_
to design vector icons that look good even drawn at 16x16 (particularly
given both ordered-subpixel rendering/display and sub-pixel positioning
and antialiasing in the renderer).
(also don't forget that the "svg" icon themes tend to bundle prerendered
and potentially hand-tweaked bitmaps for small pixel sizes like 16x16
- of course, unlike fonts, vector icons don't tend to be hinted AFAIK.
Hmm. I guess they could be autohinted to some extent, or, heh, some
color-outline-font format supporting manual hinting used for them :-) )
------------------------------
Message: 6
Date: Tue, 01 Jul 2008 03:56:33 +0300
From: Nikos Chantziaras <realnc at arcor.de>
Subject: Constant DPI regardless of resolution
To: xorg at freedesktop.org
Message-ID: <g4bvc6$ptv$1 at ger.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
After RTFM and Google, I can't seem to find a way to force xorg to use a
constant DPI value regardless of the current resolution. It calculates
the DPI with the known formula (screen dimensions and resolution). But
in my case, when changing resolution, the DFP (digital flat panel) is
set-up to simply keep the picture centered, with black borders around it
if the resolution is smaller than the DFP's native resolution. The DPI
does not change (only the resolution changes.)
Starting X with "-dpi 86" also won't help; the DPI still changes after
switching resolution (starting in 1024x768 and then going 1280x1024 for
example results in huge fonts). The desktop's environment (KDE in this
case) "Force 96DPI" is sub-optimal; my DFP is not 96DPI.
This is also an issue when running xorg in a virtual machine (the VM
window for example is 1024x768 while the monitor is running at
1280x1024). Resizing the window changes the resolution but
unfortunately xorg also changes DPI even though it shouldn't.
If there is a way, how can I force a constant DPI regardless of resolution?
------------------------------
Message: 7
Date: Mon, 30 Jun 2008 19:34:08 -0700
From: Alan Coopersmith <Alan.Coopersmith at Sun.COM>
Subject: Re: Further notes on 7.4
To: Brian Paul <brian.paul at tungstengraphics.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <486997A0.7000309 at sun.com>
Content-Type: text/plain; charset=ISO-8859-1
Brian Paul wrote:
> I don't recall other C compilers having a dependency generator option
> like gcc.
Sun cc does - we had a script form of makedepend that wrapped it in the past,
much like the old gccmakedep script.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
------------------------------
Message: 8
Date: Mon, 30 Jun 2008 22:38:49 -0400
From: Felix Miata <mrmazda at ij.net>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <486998B9.60202 at ij.net>
Content-Type: text/plain; charset=ISO-8859-1
On 2008/07/01 02:35 (GMT+0100) Glynn Clements apparently typed:
> Felix Miata wrote:
>> Sounds to me like you're using the same bogus math as typesetters and web
>> deeziners use. 8px is not half the size of 16px - it's 25%, length times
>> width. Size is area, not one single dimension. A 1600x1200 display has 4
>> times as many logical px (1,920,000) as an 800x600 display (480,000). Thus, a
>> 48x48 icon has 2304px, 2.25 times the 1024px of a 32x32 icon; 4 times as many
>> as a 24x24 (576).
> I think you missed my point, because using areas only makes the issue
> more pronounced.
Area doesn't make it any more or less pronounced. What it should make more
pronounced is the ability to recognize the disparities discussed. The
minimization of real differences into artificially smaller differences makes
the problems _look_ like smaller problems than they really are.
> My point is that you need small enough increments that you can always
> get roughly the size that you want, rather than being stuck with a
> choice between definitely too large or definitely too small.
Or use something intended to scale in the first place.
AFAICT, the technology exists for displays to be double or more the
resolution the average user has now, but the systems they're expected to be
used with are dependent on anachronisms like 96 DPI, choices between two tiny
bitmap icon size groups, and apps designed as if they were intended for print
media of fixed dimension instead of computer display screens of widely
varying size and resolution. Few would now buy those much higher resolutions
due to the tininess of objects that would result from their use encumbered by
those legacies. If the desktops could accommodate the same resolution laser
printers started with (300 or more), the increments would be too small to
matter, and scaling would bother few, or maybe no one.
> With fonts, you get that choice. But the interval between the
> available icon sizes is much larger.
As long as everyone is stuck with a tiny selection of bitmap images, that's
exactly right. It's well past time for everyone to remain stuck with them though.
>> > The 96 dpi figure was just an arbitrary value, chosen so that various
>> > common point sizes (6, 8, 12, 16) would work out to an integer number
>> > of pixels.
>> It's arbitrary all right, but not necessarily for the reason you claim. e.g.
>> at 96 DPI:
>> 6pt = 8.000px^~1.5 (not enough px per character box for all complete
>> character sets to be rendered intelligibly)
>> 8pt = 10.667px^~1.5
>> 10pt = 13.333px^~1.5
>> 12pt = 16.000px^~1.5
>> 16pt = 21.333px^~1.5
> I have no idea what you're getting at here.
You mentioned integer text sizes as a reason why 96 DPI. Few above calculate
to integers. e.g. I meant 13.333^1.5 as a character box of about 13.333 tall
by about half that width for a total of about 88.89px available per 10pt
character.
>> The reason anyone else uses it is because M$ uses/used it, and the reason for
>> that misfortunate legacy is explained on:
>> http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx
> That's interesting, but it doesn't really have any bearing on the
> notion of resolution independence.
Just tried to correct any misconception about the source of legacy.
> So long as display resolutions remain low enough that you have UI
> elements which are only a few pixels in size, the fact that you
> ultimately have to rasterise whole pixels means that you can't just
> operate entirely in physical units, in the same way that you can with
> a 300+dpi laser printer.
Right, so desktop environments need to make some big changes to permit
display devices with enough resolution to be feasible. So, this thread isn't
so much about whether people know the conflicts exist so much as it is the
posture of those trying to make the best of what is vs. those trying to push
capabilities up to a reasonable ought-to-be. I doubt anyone would complain if
the average was 300. The problems are many in dealing with the gap between
current reality and goodness, how to eliminate that gap, and living with and
minimizing the pain of the under construction mess in the meantime.
> Well, you *can*, but the artifacts are going to look a lot worse.
Maybe to people with your 15/15 vision, but less likely to people corrected
to no better than 25/25. I generally find a native size image no better or
worse than that same image blown up to 4X its native size when its native
size is only 1/4 big enough to be useful anyway. I'm a user of high
resolution in order to gain quality, not interested in stuffing more things
of smaller size into a given space.
I'm all for getting everything beyond bitmaps ASAP. Puters are plenty
powerful. Let's get them using that power to make people happy users instead
of bickering finger pointers.
--
"Where were you when I laid the earth's
foundation?" Matthew 7:12 NIV
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 35, Issue 128
*************************************
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 25
************************************
More information about the xorg
mailing list