Ok, here's a quick follow on release to 2.4.6 to fix an embarrasing
build problem in the test suite when libudev is not available.
Kristian
Dave Airlie (1):
drm: fix test makefile
Kristian Høgsberg (3):
test: Makefile.am grammar nazi
test: Avoid recursive dependency in
On Wed, 2009-04-08 at 22:09 +0300, Mihai Donțu wrote:
Until yesterday, I was using the xorg server 1.3.0. I was very satisfied with
it, but my distribution (Gentoo) moved 1.5.3 into stable and I had to
upgrade. The problem that is most annoying to me is that everything in
konsole (KDE's
On 04/08/2009 05:00 PM, Thomas Dickey wrote:
...
If only the latest release is API-stable, by definition it's not
stable.
On Wed, Apr 08, 2009 at 05:34:48PM -0400, Behdad Esfahbod wrote:
...
This cannot be deduced from that line. You need to review your math.
On Wednesday 08 April 2009
On Thursday 09 April 2009 10:39:47 Alan Cox wrote:
if someone massively resizes a window with backing store (remembering
it can be mostly offscreen) your X server explodes.
Remind us why turning it on for all windows all the time (Composite) is
better than for one window? ;o)
There
On Thu, 9 Apr 2009, Daniel Stone wrote:
On Wed, Apr 08, 2009 at 05:52:12PM -0400, Thomas Dickey wrote:
On Wed, Apr 08, 2009 at 05:34:48PM -0400, Behdad Esfahbod wrote:
On 04/08/2009 05:24 PM, Thomas Dickey wrote:
If only the latest release is API-stable, by definition it's not
stable.
This
On Thu, Apr 09, 2009 at 06:14:21AM -0400, Thomas Dickey wrote:
On Thu, 9 Apr 2009, Bill Crawford wrote:
It makes perfect sense. He's saying that (f(A) ⊢ g(B)) ⊬ (¬f(A) ⊢ ¬g(B)),
where
A is release, f is latest, B is API and g is stable ;o)
The point is not that it has to be the latest
if someone massively resizes a window with backing store (remembering it
can be mostly offscreen) your X server explodes.
Remind us why turning it on for all windows all the time (Composite) is
better
than for one window? ;o)
There is nothing in composite that requires you redirect
On Wednesday 08 April 2009 21:28:47 Alan Cox wrote:
Backing store has long been off by default in Xfree/Xorg. Fundamentally
its a dumb design issue in the concept of backing store - it means the
server has to consume huge amounts of memory keeping copies of stuff and
if someone massively
On Thu, 9 Apr 2009 13:22:45 +1000
Torgeir Veimo torg...@pobox.com wrote:
2009/4/9 Alan Cox a...@lxorguk.ukuu.org.uk
For proving fancy anti-aliasing isn't just for new apps or integrating it
into old ones, KeithP's rework of twm with render is glorious...
Is there a screenshot
He might have. His response doesn't contain any useful information.
I think you are confusing not containing information with not
understanding it
tie-in on the web-page, that's problematic since it's only the portion of
the API which has been unchanging for an extended period of time that
Hey Tom,
Have you seen this version of TWM with translucent windows used for menus ?
http://keithp.com/~keithp/render/
On 4/9/09, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Thu, 9 Apr 2009 13:22:45 +1000
Torgeir Veimo torg...@pobox.com wrote:
2009/4/9 Alan Cox
On Thu, Apr 09, 2009 at 12:35:32PM +0100, Alan Cox wrote:
On Thu, 9 Apr 2009 13:22:45 +1000
Torgeir Veimo torg...@pobox.com wrote:
2009/4/9 Alan Cox a...@lxorguk.ukuu.org.uk
For proving fancy anti-aliasing isn't just for new apps or integrating it
into old ones, KeithP's rework of
That's http://keithp.com/~keithp/talks/
Nice pictures. I also like how they demonstrate anti-aliased fonts
are unusable at small sizes.
Each to their own, I know which I find easier to read and I know what
extensive studies say people prefer as well.
Also be careful with the images to view
On Thu, Apr 09, 2009 at 11:31:18AM +0100, Alan Cox wrote:
If any of the words I have used are too long please ask for help.
In-ter-fwhat? Oh, fuck it, I'll go get a beer instead.
Seriously, let's go back to that sentence again:
Please download one of the latest releases in order to get an
On Thu, Apr 09, 2009 at 02:05:51PM +0100, Alan Cox wrote:
Each to their own, I know which I find easier to read and I know what
extensive studies say people prefer as well.
To each their own indeed.
Also be careful with the images to view them full size - if your browser
is scaling them
= there can't be that many applications using it if it was moving all the
time
So the fact there are lots of applications using it should have told you
that your interpretations were suspect
= there can't have been much testing by real applications at that point
See above.
Pretty much the
Announcing the 1.2.5 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx chipsets.
The development is driven by Novell and AMD at the time of writing, together
with a community of open source developers around this driver.
AMD provides free
On Thu, Apr 09, 2009 at 02:25:14PM +0100, Alan Cox wrote:
= there can't be that many applications using it if it was moving all the
time
So the fact there are lots of applications using it should have told you
that your interpretations were suspect
If the cairo website gives a list of
If you look at our paper here:
http://keithp.com/~keithp/talks/usenix2003/
You'll discover that the font metadata turned out to be as large as
the glyphs actually used.
And client side fonts with server caching therefore turns out to be a
wash as far as bits transferred in practice, while
I've always wondered why. It makes no sense. The network-oriented
nature of X means you should do your best to send as little data as
possible, and prerendered pixmaps are nowhere near minimal. Why isn't
fontconfig/xft and even pango in the server where it seems to belong?
It turns out to
Twas brillig at 09:31:01 09.04.2009 UTC-04 when j...@freedesktop.org did gyre
and gimble:
JG So the X11 core font design is fundamentally a mistake, which we
JG fixed.
Given this topic resurfaced again, I'd like to ask the related question:
core X fonts had the feature of being controlled by
On 04/09/2009 09:38 AM, Olivier Galibert wrote:
On Thu, Apr 09, 2009 at 02:25:14PM +0100, Alan Cox wrote:
= there can't be that many applications using it if it was moving all the
time
So the fact there are lots of applications using it should have told you
that your interpretations were
On Thu, 2009-04-09 at 20:52 +0700, Mikhail Gusarov wrote:
Twas brillig at 09:31:01 09.04.2009 UTC-04 when j...@freedesktop.org did gyre
and gimble:
JG So the X11 core font design is fundamentally a mistake, which we
JG fixed.
Given this topic resurfaced again, I'd like to ask the
On 04/09/2009 09:52 AM, Mikhail Gusarov wrote:
Twas brillig at 09:31:01 09.04.2009 UTC-04 when j...@freedesktop.org did gyre
and gimble:
JG So the X11 core font design is fundamentally a mistake, which we
JG fixed.
Given this topic resurfaced again, I'd like to ask the related
On Thu, Apr 09, 2009 at 09:31:01AM -0400, Jim Gettys wrote:
If you look at our paper here:
http://keithp.com/~keithp/talks/usenix2003/
You'll discover that the font metadata turned out to be as large as
the glyphs actually used.
And client side fonts with server caching therefore turns
On 04/09/2009 09:59 AM, Jim Gettys wrote:
Note, however, that our concept of size of fonts is fundamentally
broken: the physical size in pixels of some physical size is *very*
seldom what you actually want; what you really want is the size of a
font in terms of angle: the physical size at
Twas brillig at 10:00:44 09.04.2009 UTC-04 when beh...@behdad.org did gyre and
gimble:
BE Xft and cairo have (shared) XRDB keys for antialiasing and other
BE stuff, but not dpi. GTK+ uses XSETTINGS for those as well as DPI,
BE and those are per-screen. gnome-settings-daemon populates them
On 04/09/2009 10:03 AM, Mikhail Gusarov wrote:
Twas brillig at 10:00:44 09.04.2009 UTC-04 when beh...@behdad.org did gyre
and gimble:
BE Xft and cairo have (shared) XRDB keys for antialiasing and other
BE stuff, but not dpi. GTK+ uses XSETTINGS for those as well as DPI,
BE and
On Apr 9, 2009, at 4:03 PM, Behdad Esfahbod wrote:
On 04/09/2009 09:59 AM, Jim Gettys wrote:
The viewer is at a very different distance depending on whether the
application is on a PDA a foot from your eyes, several feet for a
desktop, and across the room for a projector.
Just define DPI
Matthias Hopf schrieb:
Announcing the 1.2.5 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx chipsets.
The development is driven by Novell and AMD at the time of writing, together
with a community of open source developers around
On Thu, 9 Apr 2009, Behdad Esfahbod wrote:
I didn't flame him. Certainly didn't mean to do that. I just said that his
Go back and read the thread, in order, before continuing.
awai
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
On Thu, 2009-04-09 at 16:01 +0200, Olivier Galibert wrote:
On Thu, Apr 09, 2009 at 09:31:01AM -0400, Jim Gettys wrote:
If you look at our paper here:
http://keithp.com/~keithp/talks/usenix2003/
You'll discover that the font metadata turned out to be as large as
the glyphs actually
Is there equivalent functionality with Xft? And whose responsibility it
is now, if this functionality is not here: applications, toolkits or
something else?
Xft provides the DPI information, the desktop permits the DPI to be
configured providing some muppet hasn't decided that is too
My point is different:
DPI by itself isn't usually interesting: you also need the distance from
the screen to understand what size font makes sense. Very seldom do you
actually want what you see is what you get on a piece of paper I
can't read a piece of paper across the room if the text is
On 04/09/2009 10:37 AM, Alan Cox wrote:
In the perfect world the monitor would report the DPI reliably to the
Xserver which would adopt it and everything would just work.
Unfortunately monitors report rather varied things, the dominant OS
product appears to ignore the monitor value entirely
Date: Thu, 9 Apr 2009 01:14:28 +0200
From: Olivier Galibert galib...@pobox.com
On Wed, Apr 08, 2009 at 07:00:02PM -0400, Patrick O'Donnell wrote:
Speaking of which -- the applications I'm maintaining are wedded to
using a writable color map, which has always been PseudoColor, which,
as you
On Thu, 2009-04-09 at 10:48 -0400, Behdad Esfahbod wrote:
On 04/09/2009 10:37 AM, Alan Cox wrote:
In the perfect world the monitor would report the DPI reliably to the
Xserver which would adopt it and everything would just work.
Unfortunately monitors report rather varied things, the
On 04/09/2009 10:55 AM, Jim Gettys wrote:
On Thu, 2009-04-09 at 10:48 -0400, Behdad Esfahbod wrote:
On 04/09/2009 10:37 AM, Alan Cox wrote:
In the perfect world the monitor would report the DPI reliably to the
Xserver which would adopt it and everything would just work.
Unfortunately
On Thu, 2009-04-09 at 10:58 -0400, Behdad Esfahbod wrote:
On 04/09/2009 10:55 AM, Jim Gettys wrote:
On Thu, 2009-04-09 at 10:48 -0400, Behdad Esfahbod wrote:
On 04/09/2009 10:37 AM, Alan Cox wrote:
In the perfect world the monitor would report the DPI reliably to the
Xserver which would
On 04/09/2009 11:10 AM, Jim Gettys wrote:
Since when you are doing certain few applications (actual WSIWYG layout,
or the use of the screen as a ruler, which we do on OLPC), you really do
want the actual DPI; it's just we *also* need to know the typical
viewing distance.
You have a very
Patrick O'Donnell wrote:
Date: Wed, 08 Apr 2009 08:36:29 -0700
From: Alan Coopersmith alan.coopersm...@sun.com
Are there any systems in which you can write a million colors to a
PsuedoColor colormap? I've not often seen PseudoColor supporting
more than 8-bit/256 colors in the real world.
And in the past, we never had the viewing distance in X11's design: our
presumption was then always desktop monitors, viewed at the usual
desktop distance). It is entirely missing from the core protocol.
One problem is that this is application dependant. I will be at normal
viewing distance
On Thu, 2009-04-09 at 16:20 +0100, Alan Cox wrote:
And in the past, we never had the viewing distance in X11's design: our
presumption was then always desktop monitors, viewed at the usual
desktop distance). It is entirely missing from the core protocol.
One problem is that this is
Date: Thu, 09 Apr 2009 11:17:25 -0400
From: Peter Harris phar...@opentext.com
Patrick O'Donnell wrote:
(Supporting TrueColor, alas, would be a royal pain, given the design
of the apps.)
... use an OpenGL fragment shader to do the
PseudoColor = TrueColor translation at CopyArea[1] time. ...
On Thu, 2009-04-09 at 10:29 -0400, Jim Gettys wrote:
Someday somehow I'll try to do some tests to check whether that's
really true with a better optimized protocol, because right now
everything that uses xft over a ssh tunnel is an horrible pain in the
ass,
I don't know what problem
On Thu, 2009-04-09 at 18:29 +0200, Xavier Bestel wrote:
On Thu, 2009-04-09 at 10:29 -0400, Jim Gettys wrote:
Someday somehow I'll try to do some tests to check whether that's
really true with a better optimized protocol, because right now
everything that uses xft over a ssh tunnel is an
Patrick O'Donnell wrote:
The RENDER extension already has mechanisms for copying PseudoColor
pixmaps to TrueColor displays, but it does not allow you to use your own
colormap.
This sounds a bit more promising, though. I guess I'll have to read
up on RENDER. Could you clarify it does not
On Thu, Apr 09, 2009 at 12:46:57PM -0400, Jim Gettys wrote:
That is downright strange. Are you comparing the same application? or
different applications?
GTK may be doing something really stupid internally, that has nothing to
do with fonts, but is related to the latency. I've suspected as
On Thu, 2009-04-09 at 12:46 -0400, Jim Gettys wrote:
On Thu, 2009-04-09 at 18:29 +0200, Xavier Bestel wrote:
On Thu, 2009-04-09 at 10:29 -0400, Jim Gettys wrote:
Someday somehow I'll try to do some tests to check whether that's
really true with a better optimized protocol, because right
On Thursday 09 April 2009, Klaus Dittrich wrote:
Matthias Hopf schrieb:
Announcing the 1.2.5 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx
chipsets. The development is driven by Novell and AMD at the time of
writing, together with
On Wed, Mar 25, 2009 at 10:21:51AM -0700, Jesse Barnes wrote:
In trying to track down the memory leak in 20704, I found that the DRI2
drawable destroy routine doesn't seem to get called when new drawables
are created and old ones destroyed (as in the glViewport case in the
bug).
Ok, sorry for
On 4/9/09, Gene Heskett gene.hesk...@verizon.net wrote:
On Thursday 09 April 2009, Klaus Dittrich wrote:
Matthias Hopf schrieb:
Announcing the 1.2.5 Release of the xf86-video-radeonhd driver.
RadeonHD is the X.org X11 driver for AMD GPG (ATI) r5xx/r6xx/r7xx
chipsets. The development
-Original Message-
From: xorg-boun...@lists.freedesktop.org
[mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Jim Gettys
Sent: Thursday, April 09, 2009 8:11 AM
To: Behdad Esfahbod
Cc: Victor Wagner; x...@freedesktop.org
Subject: Re: Documentation?
We've been missing one
-Original Message-
From: Zhenyu Wang [mailto:zhenyu.z.w...@intel.com]
Sent: Thursday, April 09, 2009 01:16
To: Jacques, Hugo
Cc: xorg@lists.freedesktop.org
Subject: Re: xf86-video-intel SDVO TV xrandr support for TV_FORMAT
On 2009.04.08 02:44:44 +0800, Jacques, Hugo wrote:
Hi
Hi,
I am using xorg xserver. i am using a OMAP based board.
My board is a 640x480 LCD with touch screen support.
I am trying to rotate the display using xrandr. But xrandr returns error.
I am also unable to run xtscal.
Output of my commands are:
r...@omap3:~# xrandr -q
Screen
On Thu, 2009-04-09 at 11:30 -0700, McDonald, Michael-p7438c wrote:
By the same argument, should that missing one value also be
applyable to Coordinates and Dimensions also? I would think a zero
width line would have the same visibility issues as a 8 point font.
Yeah, zero width lines were
The right way to attack this problem is, when you identify a broken GTK
application, get a copy of xscope (or whatever it is called these days),
and interpose it between the application and the high latency line, and
get a X protocol trace.
That would make it easy to locate the offending
Jim Gettys wrote:
Note, however, that our concept of size of fonts is fundamentally
broken: the physical size in pixels of some physical size is *very*
seldom what you actually want; what you really want is the size of a
font in terms of angle: the physical size at some distance.
As well as
This cannot be deduced from that line. You need to review your math.
On Wednesday 08 April 2009 22:52:12 Thomas Dickey wrote:
Behdad's comment doesn't make sense in English.
(Perhaps someone can help Behdad with that - or else explain to him
what API-stable might mean).
It makes perfect
-Original Message-
From: xorg-boun...@lists.freedesktop.org
[mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Jim Gettys
Sent: Thursday, April 09, 2009 11:54 AM
To: McDonald, Michael-p7438c
Cc: x...@freedesktop.org
Subject: RE: Documentation?
Would that we got a fresh
Hi,
As an additional input, my configure options are:
xorg-server-1.5.3/configure --build=i686-linux
--host=arm-angstrom-linux-gnueabi --target=arm-angstrom-linux-gnueabi
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share
Hello together!
I'm using an UMPC with a display that has 800x480 as its native resolution.
On Vista I'm also able to set 1024x600 and two other higher-than-native
resolutions (all three scaled down, not panning) and now I want to know
if this is also possible with the Intel driver on Linux.
On Thu, 2009-04-09 at 12:16 -0700, McDonald, Michael-p7438c wrote:
Would that we got a fresh slate (and all new applications); a design
done today would be very different than what we did in 1986.
That's undoubtable true since we like to think we learn from past
mistakes. Recurring
Patrick O'Donnell wrote:
So much stuff breaks with a DirectColor visual that no-one ever uses
one.
By this, I presume you mean that many clients fail to support
DirectColor correctly, (or fail to match visuals correctly) so they
break? Or are you referring to server support for
latest-releases tie-in on the web-page, that's problematic since it's
only the portion of the API which has been unchanging for an extended
period of time that would be (in the normal sense of the word) stable.
I guess one keeps something stable exactly because it wasn't at some
point. I'd
Fedora 11 Beta (xrandr 1.3 - yeah!)
If I manually execute the command...
xrandr --output LVDS1 --mode 1024x600 --panning 1280x1024
I sort of get what I want...well, the background is tiled but my tiny
1024x600 screen becomes usable with panning and I can't understand why I
can't achieve this
Our i18n team recently fixed a bug in luit and asked me to help
upstream it - while doing so, I found there's actually two luit
forks out there - one maintained with xterm and one maintained
with the rest of the Xorg modules:
http://invisible-island.net/luit/luit.html
On Wed, Apr 08, 2009 at 09:17:52AM -0700, Leif Bergerhoff wrote:
Remi Cardona wrote:
Unless you're using the closed nVidia driver, the xrandr tool will do
_exactly_ what you're looking for.
Take a look at man xrandr, especially the --pos option.
I don't think this is true. The --pos
From: Jim Gettys j...@freedesktop.org
Date: Thu, 09 Apr 2009 15:25:26 -0400
But I for one think you guys did one hell of a good job coming up with
X11. There are a lot more things right with it than there are wrong.
Most of those 20 year old programs do still work. You can't say that
about a
On Thu, 2009-04-09 at 13:49 -0700, McDonald, Michael-p7438c wrote:
I wasn't refering to backing store or save unders or any other feature
specificly. I was refering to MY impression of what I perceive as the
philosophy of the new set of developers.
I don't have the same impression, at
On Thu, 2009-04-09 at 19:08 -0400, Patrick O'Donnell wrote:
We did fix it, with composite, in a way better than before. You don't
have to run a compositing manager that does anything visual at all; you
don't have to have one iota of transparency, drop shadows, or even
anti-aliased fonts.
Patrick O'Donnell wrote:
From: Jim Gettys j...@freedesktop.org
Date: Thu, 09 Apr 2009 15:25:26 -0400
We did fix it, with composite, in a way better than before. You don't
have to run a compositing manager that does anything visual at all; you
don't have to have one iota of transparency,
72 matches
Mail list logo
