[Fwd: xorg Digest, Vol 36, Issue 24]
Regina
regina.apel at gmx.de
Thu Jul 3 02:51:25 PDT 2008
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 36, Issue 24
Datum: Thu, 03 Jul 2008 02:31:42 -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 125] (Regina)
2. [Fwd: xorg Digest, Vol 35, Issue 126] (Regina)
----------------------------------------------------------------------
Message: 1
Date: Thu, 03 Jul 2008 11:31:10 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 35, Issue 125]
To: xorg at lists.freedesktop.org
Message-ID: <486C9C5E.7040509 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-------- Original-Nachricht --------
Betreff: xorg Digest, Vol 35, Issue 125
Datum: Mon, 30 Jun 2008 16:05:36 -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: spaces in pathnames (James Cloos)
2. Re: Further notes on 7.4 (Glynn Clements)
3. Re: Further notes on 7.4 (Daniel Stone)
4. Re: Resolution indpendence (Glynn Clements)
5. Re: Further notes on 7.4 (Dan Nicholson)
6. Re: Further notes on 7.4 (Daniel Stone)
7. Re: Further notes on 7.4 (Daniel Stone)
8. Re: XvMC and Intel G33 (R. G. Newbury)
9. Re: Resolution indpendence (David De La Harpe Golden)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 Jun 2008 17:00:48 -0400
From: James Cloos <cloos at jhcloos.com>
Subject: Re: spaces in pathnames
To: xorg <xorg at lists.freedesktop.org>
Cc: Glynn Clements <glynn at gclements.plus.com>
Message-ID: <m3d4ly1vu0.fsf at lugabout.jhcloos.org>
Content-Type: text/plain; charset=us-ascii
>>>>> "Adam" == Adam Jackson <ajax at nwnk.net> writes:
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.
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?
-JimC
--
James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
------------------------------
Message: 2
Date: Mon, 30 Jun 2008 22:55:59 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Further notes on 7.4
To: Adam Jackson <ajax at nwnk.net>
Cc: xorg at lists.freedesktop.org
Message-ID: <18537.22127.994867.946587 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
Adam Jackson wrote:
> The core fonts are still listed there, but really, don't. The only one
> you want is font-misc-misc for fixed/cursor, expect the rest to leave
> the list in 7.5.
Why? It's not as if they require a lot of maintenance. Or any
maintenance at all, really.
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 3
Date: Tue, 1 Jul 2008 01:06:19 +0300
From: Daniel Stone <daniel at fooishbar.org>
Subject: Re: Further notes on 7.4
To: James Cloos <cloos at jhcloos.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080630220619.GF24418 at fooishbar.org>
Content-Type: text/plain; charset="us-ascii"
On Mon, Jun 30, 2008 at 04:30:04PM -0400, James Cloos wrote:
> >>>>> "Adam" == Adam Jackson <ajax at nwnk.net> writes:
>
> Adam> The core fonts are still listed there, but really, don't. The
> Adam> only one you want is font-misc-misc for fixed/cursor, expect the
> Adam> rest to leave the list in 7.5.
>
> There are still a wide array of very useful apps out there which require
> core fonts. 7.5 is nowhere near far enough in the future to gut the
> list of fonts included in the core release.
>
> Prune the list, perhaps, but don't gut it.
Why not? People who go out of their way to install legacy apps can also
go out of the way to install legacy fonts, surely? The vast majority of
users can just go on, content.
Bear in mind that the default for the server is now for built-in fonts
only, so you have to change it anyway.
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/0c4872a3/attachment-0001.pgp
------------------------------
Message: 4
Date: Mon, 30 Jun 2008 23:10:10 +0100
From: Glynn Clements <glynn at gclements.plus.com>
Subject: Re: Resolution indpendence
To: xorg at lists.freedesktop.org
Message-ID: <18537.22978.434772.600770 at cerise.gclements.plus.com>
Content-Type: text/plain; charset=us-ascii
James Cloos wrote:
> We should tell the apps our real dpi, but also our preferred font size.
>
> On harware like a moko you may want to use a 5 or 6 pt font. On three
> metre projection screen you might choose a 72+ pt font.
And what happens when you log into a single account from multiple X
terminals?
This is where choices like "always use 8pt" or "always use 12px" fail.
What I need is more like "at least 8pt AND at least 12px", and have it
pick the smallest hand-tuned bitmap which satisfies both constraints.
But some applications may be further constraints, e.g. I may need to
be able to display 2 windows side by side, with 80 columns of text in
each, even if I have to lean forward a bit when reading it.
--
Glynn Clements <glynn at gclements.plus.com>
------------------------------
Message: 5
Date: Mon, 30 Jun 2008 15:22:25 -0700
From: "Dan Nicholson" <dbn.lists at gmail.com>
Subject: Re: Further notes on 7.4
To: "Adam Jackson" <ajax at nwnk.net>
Cc: xorg at lists.freedesktop.org
Message-ID:
<91705d080806301522p197ec841tb27c3ac2f46d60fe at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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.
- makedepend: The mesa build depends on this, so you can't get through
a standard X build without it.
- imake/xorg-cf-files: Sadly, some 3rd party X packages still use imake.
--
Dan
------------------------------
Message: 6
Date: Tue, 1 Jul 2008 01:30:16 +0300
From: Daniel Stone <daniel at fooishbar.org>
Subject: Re: Further notes on 7.4
To: Glynn Clements <glynn at gclements.plus.com>
Cc: xorg at lists.freedesktop.org
Message-ID: <20080630223016.GG24418 at fooishbar.org>
Content-Type: text/plain; charset="us-ascii"
On Mon, Jun 30, 2008 at 10:55:59PM +0100, Glynn Clements wrote:
> Adam Jackson wrote:
> > The core fonts are still listed there, but really, don't. The only one
> > you want is font-misc-misc for fixed/cursor, expect the rest to leave
> > the list in 7.5.
>
> Why? It's not as if they require a lot of maintenance. Or any
> maintenance at all, really.
Yes, but they're an enormous pain for our users who are just trying to
bootstrap from scratch. Most users who boostrap (and I'm making a
sweeping generalisation, with a broad basis on what I've seen on both
the list and on IRC) are trying to do it for one of two reasons: either
embedded, or trying to get a new server/driver stack up.
The former really don't want core fonts, and we shouldn't be
recommending they install it. Hence they fall out of the core
distribution.
The latter already have core fonts from their distro.
I've said before that I consider LFS and the like a relatively
uninteresting case, and people going out of their way to install weird
or proprietary apps can find and install the fonts. It's not a huge
amount of documentation to get them to fetch and install the core fonts.
Distributions like RHEL which see a lot of proprietary/Motif app usage
will almost certainly ship with more than the bare minimum set of core
fonts, and I'd imagine OSes like Solaris where this gets used a lot will
also continue to install core fonts. But for our userbase, it's not
hugely relevant: all they know is that builds are brittle and their
server can never find this fixed thing and oh god freetype.
Also, they never change, so what's the benefit in aggregating them in
our sixish month release cycle? Just have a wiki page with a link to the
original versions and instructions on how to install them. Everyone
benefits (right now, font installation and configuration isn't
well-documented at all, and could certainly benefit from good docs, and
does this not act as a good motivator?).
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/24e2a210/attachment-0001.pgp
------------------------------
Message: 7
Date: Tue, 1 Jul 2008 01:33:14 +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: <20080630223314.GH24418 at fooishbar.org>
Content-Type: text/plain; charset="us-ascii"
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.
> - 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. :)
> - imake/xorg-cf-files: Sadly, some 3rd party X packages still use imake.
Right, but the ones which still use a bizzare build system will probably
require other weird crap, so if it's well documented how to get a
functioning imake setup installed, that shouldn't be a problem. There's
nothing stopping distributions carrying them, since they never change,
making it trivial for 99% of our users.
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/cf4cffed/attachment-0001.pgp
------------------------------
Message: 8
Date: Mon, 30 Jun 2008 18:56:48 -0400
From: "R. G. Newbury" <newbury at mandamus.org>
Subject: Re: XvMC and Intel G33
To: xorg at lists.freedesktop.org
Message-ID: <486964B0.9020705 at mandamus.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Zhenyu Wang wrote
>
>> Does your log have a line like "[XvMC] i915_xvmc driver initialized"?
>> My G33 died last week, I haven't tried to run it recently.
>
> No, nothing like that as far as I can see. I'm attaching the complete
> contents of /var/log/Xorg.0.log now, maybe you can spot something out of the
> ordinary?
>
>> Current driver doesn't require to manually set libIntelXvMC.so path any
>> more.
>
> Okay. I'll leave it at the default ("libXvMC.so.1") then.
Try playing your file using mplayer -vo xvmc -vc ffmepg12mc ( or some of
the other filters listed by 'mplayer -vc help')
Note that xvmc only works for surfaces (frames) up to 720x568 in
size....Well it *does* work above that size, but something else is
munged and the picture is overlaid and pixelated with a bright green
image. Nobody seems to know what causes this.. At least, no-one has
jumped forward with an answer.. Zhenyu has done great work on xvmc but
this is NOT xvmc and I don't think he gets paid to play with this even
though he does work for Intel!
Geoff
------------------------------
Message: 9
Date: Tue, 01 Jul 2008 00:05:23 +0100
From: David De La Harpe Golden <david.delaharpe.golden at gmail.com>
Subject: Re: Resolution indpendence
To: Nicolas Mailhot <nicolas.mailhot at laposte.net>
Cc: xorg at lists.freedesktop.org
Message-ID: <486966B3.9080502 at googlemail.com>
Content-Type: text/plain; charset=UTF-8
Nicolas Mailhot wrote:
>> Nothing that exists today works at all with high-density displays -- the
>> Nokia tablets still just always smash the DPI to 96 or so, because
>
> because bad software assumes 96dpi, and breaks otherwise.
>
> The rest are just excuses.
heh.
I do think it might be useful, in these days of compositing managers, to
allow per-window resolution and zoom control.
Soeren made the point about toolkits being able to find out the physical
screens dimensions for a single merged logical screen from EDID info,
would probably be the highest-quality-drawing-possible solution, but
might place too much burden on the toolkits to DTRT ?
Here's some half-formed thoughts, just as a talking point, probably old
ground to quite a few people. I'm hazy on ICCCM and wm<->toolkit comms
in general, so I may well be getting some details wrong:
*** invent a _NET_WM_PHYS_RES _window_ xproperty taking X and Y
resolution values (if they have to be integers due to x protocol things,
make them dots per hundred inches or something).
If a window gets a _NET_WM_PHYS_RES = (120.0, 120.0) or whatever
property set, then an aware toolkit just uses that preferentially to any
overall screen DPI/physical size info for that window. When that
property is updated by the window/compositing manager, the
[resolution-independent vector gui of course ;-) ] toolkit just does an
xrandr-like adjustment for the new DPI - the major toolkits afaik
already do that for screen changes, so the code paths basically exist
already?
(I suggest resolution rather than a physical window size measurement
because it won't have to change so often under mere window reshapes).
Then, when windows are dragged from physical screen to physical screen
within the single xrandr merged logical screen, the compositing window
manager adjusts the _NET_WM_PHYS_RES_DPI * (and probably the pixel
size of the window, to preserve physical size). That way, I could drag
an A4 window from one display to the next, and it would stay physically
A4 sized.
Yay!
(* finding out the individual screen physical dpis and arrangement the
"hard way" I guess by aforementioned EDIDs and/or some new user settings
So I guess this proposal does not quite obviate the need for additional
screen-level data discovery capabilities, just shifts most of the burden
onto the few compositing window managers rather than the many toolkits...)
When a window spans multiple screens (the hard case), the compositing
window manager supplies the max of the DPIs of the screens as the
xproperty (so the toolkit doesn't need to think about drawing with more
than one DPI to different regions of the same window...), and
app-transparently (presumably 3d-hardware banging) zooms out from the
rectangles for the other screens (n.b. if it doesn't do that magic
subregion rescaling for this case, hey, that's no worse than today...).
That might require some associated input event rescaling system to work
perfectly, but I believe that's being worked on anyway...
- that way, a physically A4 sized window dragged to span parts of four
screens of different reses stays physically A4 sized (assuming properly
configured physical screen positions with dead zones for any gaps and
the like. Hmm. That's tricky if the dead zones are measured in pixels.
Maybe also need to be able to specify the physical screens relative
positions in physical units for perfection...)
A compositing/window manager could/should supply a zoom setting and
(presumably 3d-hardware banging) zooming, so that (in particular)
resolution-unaware/legacy bitmap apps can be zoomed into WITHOUT abusing
physical resolution settings for zooming.
*** It might also be "necessary" to provide an X extension to allow a
compositing window manager to supply a _fake_ screen dpi (because that's
what non _NET_WM_PHYS_RES apps will use) to individual legacy bitmappy x
clients so that they can be forced to think the screen is 96 dpi, then
zoomed into without their awareness.
*** The compositing window manager could ALSO provide a 1:2 etc. scale
setting on a per application or per window basis, by just supplying
different _NET_WM_PHYS_RES than realistic. (and of course a default
that users can just tweak with a slider or whatever away from 1:1).
*** Or it may be better not to do that, and always keep NET_WM_PHYS_RES
realistic (except in obscure cases ++), but ALSO introduce a
NET_WM_PLEASE_SCALE_TO == 1.5 or whatever xproperty that aware toolkits
can honour.
N.B. The application-handled scaling by unrealistic PHYS_RES or
PLEASE_SCALE_TO is quite different to application-transparent zooming
being done by the compositing manager! (Duh, but just in case)
(++ One could e.g. "pixel-perfect" preview a physical-size-adaptive gui
for a small, hires display on a large 100DPI developer's workstation by
e.g. setting the window's pixel size to 640x480 and the
_NET_WM_PHYS_RES_DPI to 250,250, "fooling" the _NET_WM_PHYS_RES_DPI
aware toolkit into thinking its drawing for the small, hires device
rather than a big, low-res device.)
Something similar might work for color profiles. Maybe.
This has problems for multi-window apps. At worst, there'd be a
potentially unsightly resize event just after an app opens another
window, BUT apps could e.g. assume the dpi of the first window they open
for subsequent windows (the common case), set the window property to
acknowledge the DPI the app thinks it is, and would only have to rescale
if the window manager then corrects it.
*** Hmmm. Maybe there should be separate APP_REQUESTED_PHYS_RES
USER_SPECIFIED_PHYS_RES parameters (like window pixel sizes
themselves!), so that an app that knows it was made only to work
decently on a 96 dpi display can say so, as a sop to the diehard
bitmap-gui-drawers - then the compositing wm can zoom it by
default/according to user tastes on hires displays.
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 35, Issue 125
*************************************
------------------------------
Message: 2
Date: Thu, 03 Jul 2008 11:31:38 +0200
From: Regina <regina.apel at gmx.de>
Subject: [Fwd: xorg Digest, Vol 35, Issue 126]
To: xorg at lists.freedesktop.org
Message-ID: <486C9C7A.4070005 at gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-------- 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
*************************************
------------------------------
_______________________________________________
xorg mailing list
xorg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
End of xorg Digest, Vol 36, Issue 24
************************************
More information about the xorg
mailing list