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