[Fwd: xorg Digest, Vol 35, Issue 126]
Regina
regina.apel at gmx.de
Thu Jul 3 02:31:38 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 35, Issue 126
Datum: Mon, 30 Jun 2008 16:30:03 -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: [ANNOUNCE] xserver 1.4.99.905 (Simon Thum)
2. Re: Further notes on 7.4 (Dan Nicholson)
3. Max resolution of Intel Graphics Chipsets (Erwin Rol)
4. Re: Further notes on 7.4 (Daniel Stone)
5. Re: Resolution indpendence (Glynn Clements)
6. Re: Max resolution of Intel Graphics Chipsets (Tomas Carnecky)
7. Re: Further notes on 7.4 (James Cloos)
8. Re: spaces in pathnames (Glynn Clements)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Jul 2008 01:05:45 +0200
From: Simon Thum <simon.thum at gmx.de>
Subject: Re: [ANNOUNCE] xserver 1.4.99.905
To: Adam Jackson <ajax at redhat.com>
Cc: xorg-announce at lists.freedesktop.org, xorg at lists.freedesktop.org
Message-ID: <486966C9.9050105 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Adam Jackson wrote:
> git tag: xorg-server-1.4.99.905
I'm missing that one (at least in the web interface).
Also missing bug#9156 (0050165a67bb462e0bf644a11644ad9d587c62bb). My
impression was that it got ACKed sufficiently.
Regards,
Simon
------------------------------
Message: 2
Date: Mon, 30 Jun 2008 16:11:52 -0700
From: "Dan Nicholson" <dbn.lists at gmail.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:
<91705d080806301611h19b0a1a4yc8253bf8170ab767 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 30, 2008 at 3:33 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> On Mon, Jun 30, 2008 at 03:22:25PM -0700, Dan Nicholson wrote:
>> On Mon, Jun 30, 2008 at 11:54 AM, Adam Jackson <ajax at nwnk.net> wrote:
>> > Note that almost all of the graphics demos and core font utilities are
>> > gone in that list. Yes, this is intentional. xeyes is not a critical
>> > component of the modern desktop. Run them if you want, but they're not
>> > part of the core release anymore.
>>
>> Just a couple thoughts looking over the pruned list. I'm not
>> necessarily pushing for these to go back in, but just considering both
>> sides of the coin.
>>
>> - twm/xdm: Certainly legacy in the window/display manager world, but
>> it seems strange to install X without one of each. Also, the default
>> xinitrc runs twm, xclock and xterm, none of which would be available
>> with the core X installation.
>
> 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.
>> - makedepend: The mesa build depends on this, so you can't get through
>> a standard X build without it.
>
> 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.
--
Dan
------------------------------
Message: 3
Date: Tue, 01 Jul 2008 01:18:04 +0200
From: Erwin Rol <mailinglists at erwinrol.com>
Subject: Max resolution of Intel Graphics Chipsets
To: xorg <xorg at lists.freedesktop.org>
Message-ID: <1214867884.20839.40.camel at eir.home.erwinrol.com>
Content-Type: text/plain
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?
TIA,
Erwin Rol
------------------------------
Message: 4
Date: Tue, 1 Jul 2008 02:20:50 +0300
From: Daniel Stone <daniel at fooishbar.org>
Subject: Re: Further notes on 7.4
To: Dan Nicholson <dbn.lists at gmail.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080630232050.GI24418 at fooishbar.org>
Content-Type: text/plain; charset="us-ascii"
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 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. 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?
Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xorg/attachments/20080701/48fe56cb/attachment-0001.pgp
------------------------------
Message: 5
Date: Tue, 1 Jul 2008 00:25:08 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <18537.27476.183792.615118 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Steven J Newbury wrote:
> > To make 1280x1024 at 120dpi look exactly like 1024x768 at 96dpi, just with
> > higher-quality, you would need to either provide another version of
> > every icon, or you would have to tolerate rescaled icons.
>
> Every version of Windows from Windows95 (I think) had a set of high
> resolution (large) icons for this very reason.
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.
> > If the original icons are 16x16 pixels, the higher resolution versions
> > need to be 20x21.33. And what you do about the extra 0.33 pixel is far
> > from straightforward.
>
> 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.
> > The interface between software components needs to be rigid, but the
> > interface between the computer and a human less so. Users are normally
> > asking for more DWIM, not less.
> >
> > [Much of the time, it's because they don't really understand the
> > consequences of what they're asking for, and wouldn't like it if they
> > got it. But that's not always the case.]
>
> I'm not sold on this. Computers currently lack sufficient context and
> intelligence to achieve DWIM in any way that doesn't really annoy a very
> large proportion of the userbase. Until we get to AI, I think computers
> should do as they're told and respond in a predictable manner.
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.
> > > This just makes no sense. If the true DPI is 220 on a decent size
> > > screen, text at 12pt will be unreadable by most if the system DPI is
> > > fixed to 96! It will only give the expected (readable) result by either
> > > setting a lower screen resolution or by using the true DPI to render the
> > > text!
> >
> > If the true resolution is 220 dpi, you will likely get the best
> > overall results by pretending that it's 192 dpi, i.e. *exactly* twice
> > 96 dpi[1]. The difference between 192 and 220 is just under 15%, which
> > is noticable but not critical, but you can then rescale everything by
> > exactly 2:1.
>
> Perhaps you should tell the hardware manufacturers?
Why? There's no reason for the hardware to actually be 192 dpi.
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.
> > Fonts actually get rendered at twice the resolution (or, if you have a
> > hand-tuned bitmap designed for 24pt @ 96dpi, you would use the same
> > bitmap for 12pt @ 192dpi), while icons just have every pixel drawn as
> > a 2x2 pixel square. No blurring, no jaggies.
>
> Or you could use outline fonts and vector graphics for icons rendered
> with sub-pixel anti-aliasing. Little perceivable blurring, full
> resolution and correct scaling. It would be interesting to see which
> looked better...
I already know the answer to that. At least, *my* answer. Whenever I'm
confronted by grey pixels, my first action is to figure out how to
make it use a bitmap.
If the resolution is low enough that you notice the jaggies on non-AA
outline fonts, a hand-tuned bitmap will win out over filtering every
time. Actually, even tolerating the jaggies may win out over AA.
> > The end result is likely to be a lot nicer than if you insist on
> > treating point sizes as sacrosanct, scaling everything by exactly
> > 2.291666:1 (220:96).
>
> 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".
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 6
Date: Tue, 01 Jul 2008 01:26:10 +0200
From: Tomas Carnecky <tom at dbservice.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: <48696B92.8070105 at dbservice.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
...
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
------------------------------
Message: 7
Date: Mon, 30 Jun 2008 19:27:12 -0400
From: James Cloos <cloos at jhcloos.com>
Subject: Re: Further notes on 7.4
To: xorg at lists.freedesktop.org
Message-ID: <m31w2e1p20.fsf at lugabout.jhcloos.org>
Content-Type: text/plain; charset=utf-8
>>>>> "Daniel" == Daniel Stone <daniel at fooishbar.org> writes:
Daniel> Why not? People who go out of their way to install legacy apps
Daniel> can also go out of the way to install legacy fonts, surely? The
Daniel> vast majority of users can just go on, content.
They don't have to go out of their way.
Even Emacs won't work out of the box (except for snapshots compiled from
CVS HEAD) w/o core fonts.
A subset is OK, but misc-misc and cursor-misc is too small of a subset.
Maybe adobe-100 and bitstream-100 might cover most of the remaining
mainstream apps. At least for latin1 users.
Daniel> Bear in mind that the default for the server is now for built-in
Daniel> fonts only, so you have to change it anyway.
Yes. I didn't upate the ebuild to force --disable-builtin-fonts because
I presumed that external fontpath entries would also work.
Bad presumption. Several apps broke. And latin1 only is an unfortunate
default in and of itself.
Had to recompile.
At least dolt makes a recompile *wildly* faster than it had been.
Of course, if no one bothers with anything other than the individual
directory, and the distributions disable-builtin-fonts and make the
necessary fonts dependencies for the relevant apps, it doesn't much
matter what fonts are in module-list.txt.
Let?s then at least be sure to make sure our customers (as it were)
understand the implications of dropping core fonts from the xserver?s
dependency list when they make their packages. (Asuming the follow
the recomendations of module-list.txt.
-JimC
--
James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
------------------------------
Message: 8
Date: Tue, 1 Jul 2008 00:30:21 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: spaces in pathnames
To: James Cloos <cloos at jhcloos.com>
Cc: xorg <xorg at lists.freedesktop.org>
Message-ID: <18537.27789.957682.79931 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
James Cloos wrote:
> Adam> More broadly, it's probably time to deprecate startx and xinit,
> Adam> strongly recommend the use of a display manager like gdm, and
> Adam> write a minimal replacement in some sensible subset of bash/ksh.
>
> I still regularly recommend avoiding display managers and running
> startx at the vt command line. /Everything/ works better that way.
That requires the user to be root, or the X server to be setuid root.
It also means that both the X server and the desktop session inherit a
bunch of environment from the console session, which may not be
appropriate.
> But I would certainly not object were the sample startx written in
> something other than sh. Is there any reason not to write it in C?
That already exists; it's called "xinit".
startx is just a front-end to xinit. That's why it's a script: so it
can be easily customised.
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 35, Issue 126
*************************************
More information about the xorg
mailing list