[Fwd: xorg Digest, Vol 35, Issue 127]
Regina
regina.apel at gmx.de
Thu Jul 3 02:32:06 PDT 2008
-------- 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
*************************************
More information about the xorg
mailing list