On Sun, Dec 4, 2011 at 6:11 PM, Donald McLachlan
donald.mclach...@crc.ca wrote:
Hi,
I don't know where to start to resolve this problem and guessed maybe this
is a good place to start. If not, please point me in the right direction.
Our ultimate goal is to stream 8k resolution video using
On Mon, Nov 28, 2011 at 4:49 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Am 28.11.2011 10:35, schrieb Christoph Bartoschek:
Now one has to look at
(*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects);
Here is what I see so far:
- damagePolyRectangle is called for 2044
On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Hi,
I still have a huge performance problem with Xorg. One application that
painted 2 Mio rectangles on the screen within a second or so with XFree86
needs about a minute with Xorg.
Most of the time is
On Sun, Nov 27, 2011 at 9:40 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Am 27.11.2011 16:13, schrieb Maarten Maathuis:
On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Hi,
I still have a huge performance problem with Xorg. One
On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
I have new information. I am no longer sure whether it is a problem with
EXA.
I have a testcase that currently takes 90 seconds to draw all rectangles. I
see that in damage.c two functions are mainly used:
On Mon, Nov 28, 2011 at 7:43 AM, Maarten Maathuis madman2...@gmail.com wrote:
On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
I have new information. I am no longer sure whether it is a problem with
EXA.
I have a testcase that currently takes 90 seconds
On Tue, Oct 11, 2011 at 10:31 PM, Christopher Harvey
ch...@basementcode.com wrote:
I'm having problems with an Intel card (82915G/GV/910GL) running in 8 bit
colour mode. I could post a screenshot if required, but basically the screen
is gray scale and some (but not all) of the pixels seem to
On Wed, Nov 24, 2010 at 11:03 AM, Tim Beaulen tbsc...@gmail.com wrote:
Luc,
I completely agree with you.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info:
On Tue, Nov 23, 2010 at 4:27 PM, Luc Verhaegen l...@skynet.be wrote:
On Tue, Nov 23, 2010 at 10:25:33AM -0500, Gaetan Nadon wrote:
On Tue, 2010-11-23 at 13:57 +0100, Luc Verhaegen wrote:
It is clear that this is not a normal security breach, as this
commit is
fully in line with the
On Wed, Nov 17, 2010 at 10:34 AM, Kai-Uwe Behrmann k...@gmx.de wrote:
Am 16.11.10, 19:21 -0500 schrieb Matt Turner:
On Tue, Nov 16, 2010 at 3:38 AM, Kai-Uwe Behrmann k...@gmx.de wrote:
ATI and Nvidia ship separate version of libGL.so, for Linux and probably
for
other operating systems. Now
On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen
ei...@opera.com wrote:
What guarantees does X give when it comes to the order of events
generated in relation to processing of the requests sent by the client?
(Also, of course: To which degree does various implementations of X
On Wed, Oct 20, 2010 at 2:57 PM, Eirik Byrkjeflot Anonsen
ei...@opera.com wrote:
Maarten Maathuis madman2...@gmail.com writes:
On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen
ei...@opera.com wrote:
What guarantees does X give when it comes to the order of events
generated
On Fri, Jul 2, 2010 at 12:19 PM, CSJ changsi...@gmail.com wrote:
Hi,
I am writing a script to output to external monitor automatically when it is
connected.
But now I have no idea about what name will be used for internal monitor in
xrandr.
some are LVDS and some are DP1
In recent versions
On Thu, Jun 10, 2010 at 8:56 PM, Corbin Simpson
mostawesomed...@gmail.com wrote:
2010/6/10 Yves De Muyter y...@alfavisio.be:
Is there any documentation available about the differences between
exa_mixed and exa_driver ? Is exa_driver like complete handover of
pixmap migration to the driver ?
Everyone got a mail containing their email in the title, the fact that you
can still post here means you're not the one ;-)
Maarten.
On Fri, May 28, 2010 at 10:10 AM, Super Biscuit super_bisq...@yahoo.comwrote:
Let me put it this way. If I am spamming the list, then anyone who uses
ATT or
I am not a member, which says something already. But in short
everything surrounding the board has never tempted to sign up or vote.
Apart from hosting a few servers i never knew what they were doing.
This situation has somewhat improved but it's still vague. At the
moment i still do not feel the
On Thu, Dec 17, 2009 at 10:40 PM, Nikos Chantziaras rea...@arcor.de wrote:
On 12/17/2009 10:54 PM, dolphinling wrote:
On 12/14/2009 04:44 PM, Nikos Chantziaras wrote:
The longer the system runs, the more RAM X eats. After about 5 hours of
uptime, I get this:
running xserver git by any chance?
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
On Fri, Sep 25, 2009 at 8:35 PM, Sebastian Glita gls...@yahoo.com wrote:
Yes,
patch URIs accepted. tx.
S.
- Original Message
From: Maarten Maathuis madman2...@gmail.com
To: Sebastian Glita gls...@yahoo.com
Cc: xorg@lists.freedesktop.org
Sent: Friday, September 25, 2009 8:12
On Mon, Sep 14, 2009 at 12:27 PM, Sebastian Glita gls...@yahoo.com wrote:
Hello,
I use xorg-server/xf86-video-nouveau/nouveau-drm/mesa/libdrm et.al. from
git.freedesktop.org. [A 2-3 days update solved the trouble with console
switching, always restarting Xorg/gdm. Great relief.]
Since 1-2
That would suggest creating a GC that completely bypasses exa.
The proper solution seems like adding more indices or at least
detecting that the indices are being used.
I'll write a patch as soon as my system is in order again.
Maarten.
___
xorg
A screenshot or something might help. But this is probably not related
to mesa, unless you are running compiz or something like that.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Common sense (and the fact that the error says BadRegion here) suggest that
reg = XFixesCreateRegion( display, rec, 1);
This region number is no longer valid after you close the display.
Doing this a 2nd time after setting nRect = 0 will fix it.
Maarten.
Please don't think i know what you are actually trying to do, i solved
this like you would a puzzle. First guess happened to work.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
And this region is some property of the root window?
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
My guess is that this some early version of dri2 (which was never
actually used), there is probably a --disable-dri2 or something like
that.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
They can never be replaced by evdev, because evdev is linux-only. But
yes, evdev is often used on linux platforms, but it does need a
working hal.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
You can only addmode after newmode.
I would expect a monitor to have it's native resolution in edid. Maybe
you only have a single link dvi (which lacks the bandwith for your
native resolution)?
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
xf86-video-nv which i guess you're using doesn't unconditionally
support dual link dvi. Some bios'es don't init it appearantly.
There is an option to force it, but you could end up with a blank screen.
Option AllowDualLinkModes
Maarten.
___
xorg
2009/6/4 Michel Dänzer mic...@daenzer.net:
On Thu, 2009-05-28 at 15:07 +0400, Evgeny M. Zubok wrote:
Ville Syrjälä syrj...@sci.fi writes:
Just set the alignment to your fixed pitch value and it should work,
shouldn't it?
Great! Good idea! I have tried to set up pitch align
From a performance pov an accelerated shadow framebuffer arrangement
is probably much faster. Assuming it has some dma capability.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I personally wouldn't mind a kill all grabs button/key/whatever. Even
if you can debug a grab issue, you don't always have the time or the
right machine (debugging symbols and friends) to do it.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
There is probably also a textured Xv adapter, have you double checked
which one you are using?
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
set_mode_major is not exclusive to kernel modesetting.
Is the driver api breakage neccesary? If so you definately need to
bump something somewhere.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
Section Extensions
Option MIT-SHM Disable
EndSection
Should work, providing you don't have an extension section already.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I think Xv is meant to also work for overlays, which obviously won't
work on a pixmap. Maybe it's a safety so application developers don't
do anything stupid.
Maarten.
On Fri, Apr 10, 2009 at 11:30 AM, Yuan Austin shengquan.y...@gmail.com wrote:
On Thu, Apr 2, 2009 at 3:59 PM, Shengquan Yuan
You can argue against the config system, xml is not ideal for manual editing.
But, having hinted, aliased fonts isn't impossible. It's pretty simple
actually. Providing you have a suitable freetype version.
So please put your ranting into perspective.
Maarten.
Several things i see.
1: you are throwing away bits in the colors
2: you should undo the mangling in the read function (the system
doesn't understand your strange layout)
3: the alpha channel is in the upper 8 bits on little endian systems
(typically) for A8R8G8B
4: read/write are used by more
You could hack wrapped fb support into the fbdev driver, but that will
only work for software rendering in X. And you'll loose some
performance because every pixel access goes through a wrapper
The vermillion driver has a simple wfb implementation
Committed as
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=da6bbca07c796c69172a649405474f03bee66754
Please provide git patches in the future (it's easier for both sides).
Maarten.
On Fri, Feb 20, 2009 at 3:10 AM, Emilio Jesús Gallego Arias
egall...@babel.ls.fi.upm.es wrote:
It seems
While we're on this subject, i have a question as well (same file, line 175).
if(event)
widen(event_sequence, event-full_sequence);
What purpose does that serve?
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
Maybe try the http://lists.freedesktop.org/mailman/listinfo/intel-gfx list?
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
commit 734b23e5982e171031077a2d5d6b5dc2a12e1a70 should fix the problem.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I'll wait a bit to see what the preferred solution is, but i see three
options atm.
- A wrapper function in fbcopy.c
- A define in fb.h, silently converting fbFoo into miFoo
- User side fixes
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
I comitted a slightly different patch.
I found out that all clipping possibilities are converted to regions
in the end, so this should be enough.
http://cgit.freedesktop.org/xorg/xserver/commit/?id=00226d0b589595cdd45c75e7e28237334a8883b1
You can put the patch on the wiki
On Fri, Feb 6, 2009 at 1:21 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
2009/2/6 Maarten Maathuis:
If you were really seeing a duplicate of a git commit list, then you
would see a whole different picture. For you patches may just be
noise, but that's not the case for everyone.
So ok
On Fri, Feb 6, 2009 at 4:21 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote:
2009/2/6 Maarten Maathuis:
It gives people time to check, review and/or complain about patches.
Now that the xorg-devel list was made, it will obviously move there.
I certainly check patches that catch my eye
---
exa/exa_accel.c | 76 ++--
exa/exa_priv.h| 25 +
exa/exa_render.c | 17 +---
exa/exa_unaccel.c | 50 ++
4 files changed, 149 insertions(+), 19 deletions(-)
diff --git
---
exa/exa_accel.c | 43 ---
exa/exa_priv.h| 16
exa/exa_render.c | 17 +
exa/exa_unaccel.c | 27 +++
4 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/exa/exa_accel.c
---
exa/exa_accel.c |4 +-
fb/fb.h | 37 --
fb/fbcopy.c | 331 +--
fb/fboverlay.c |2 +-
fb/fboverlay.h |2 +-
fb/fbwindow.c |2 +-
mi/Makefile.am |1 +
mi/mi.h | 42 +++
mi/micopy.c |
On Wed, Feb 4, 2009 at 10:56 PM, Alexander Larsson al...@redhat.com wrote:
On Wed, 2009-02-04 at 14:46 +0100, Alexander Larsson wrote:
On Wed, 2009-02-04 at 13:38 +0100, Alexander Larsson wrote:
I found what I think is a bug in XCopyArea.
If you copy a pixmap to a window and some of the
On Thu, Feb 5, 2009 at 7:13 PM, Michel Dänzer mic...@daenzer.net wrote:
On Thu, 2009-02-05 at 17:17 +0100, Maarten Maathuis wrote:
core glyphs before and after are within an error margin of 1%.
Cool, thanks for verifying it.
--
Earthling Michel Dänzer |http
---
exa/exa_accel.c | 77 ++--
exa/exa_priv.h| 25 +
exa/exa_render.c | 17 +---
exa/exa_unaccel.c | 51 +++
4 files changed, 151 insertions(+), 19 deletions(-)
diff --git
On Thu, Feb 5, 2009 at 7:28 PM, Michel Dänzer mic...@daenzer.net wrote:
On Thu, 2009-02-05 at 19:16 +0100, Maarten Maathuis wrote:
On Thu, Feb 5, 2009 at 7:13 PM, Michel Dänzer mic...@daenzer.net wrote:
On Thu, 2009-02-05 at 17:17 +0100, Maarten Maathuis wrote:
core glyphs before and after
---
exa/Makefile.am |3 ++-
exa/exa_accel.c | 44 ++--
exa/exa_priv.h |6 +-
exa/exa_render.c| 14 --
exa/exa_unaccel.c | 15 +++
fb/fbcopy_helpers.c |6 +++---
fb/fbcopy_helpers.h | 12
On Wed, Feb 4, 2009 at 8:32 AM, Michel Dänzer mic...@daenzer.net wrote:
On Wed, 2009-02-04 at 00:29 +0100, Maarten Maathuis wrote:
I hope the changes are coming to an end. I still need to know if there
are any external users of fbDoCopy that would care for a wrapper. I'm
assuming
---
exa/exa_unaccel.c | 30 +++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d56f589..a521497 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -290,9 +290,14 @@ ExaCheckGetSpans (DrawablePtr
---
exa/Makefile.am |3 ++-
exa/exa_accel.c | 44 ++--
exa/exa_priv.h |6 +-
exa/exa_render.c| 14 --
exa/exa_unaccel.c | 15 +++
fb/fbcopy_helpers.h |5 +
6 files changed, 69
---
exa/exa_accel.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index f72a08a..b70222a 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -149,6 +149,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr
---
exa/exa.c | 141 ++---
1 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 42b664f..5faeee0 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -188,6 +188,7 @@ exaDestroyPixmap (PixmapPtr pPixmap)
{
- Compatibility wrappers, if deemed neccesary will come later.
---
fb/Makefile.am |3 +-
fb/fb.h | 37 +-
fb/fb24_32.c|4 +-
fb/fbcopy.c | 342 ++-
fb/fbcopy_helpers.c | 367
Per request by anholt and others, i have sent the patches as plain text.
The only change from the last set is that i splitted out a few fb
functions into a seperate file, enhanced them slightly and added a few
defines to allow exa to use them. My attempts to split it out into mi,
gave me very
---
exa/exa.c | 219
exa/exa_priv.h| 33 -
exa/exa_unaccel.c | 98 +---
3 files changed, 234 insertions(+), 116 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 496b898..42b664f 100644
---
---
exa/exa.c | 11 +++
exa/exa_priv.h | 12 +++-
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index ba063bb..496b898 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -41,6 +41,8 @@ static int exaScreenPrivateKeyIndex;
DevPrivateKey
Found a potential bug in exaValidateGC, which should be fixed now.
I hope the changes are coming to an end. I still need to know if there
are any external users of fbDoCopy that would care for a wrapper. I'm
assuming that functions that changed their return value from void to
Bool pose no issue,
---
exa/exa_accel.c |7 +--
exa/exa_priv.h|4
exa/exa_unaccel.c | 30 ++
3 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 10e7914..02858f1 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
---
exa/exa.c | 233 +
exa/exa_priv.h| 33 +++-
exa/exa_unaccel.c | 98 ---
3 files changed, 248 insertions(+), 116 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 496b898..58d1a7d 100644
---
---
exa/exa.c | 141 ++---
1 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 58d1a7d..033b353 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -188,6 +188,7 @@ exaDestroyPixmap (PixmapPtr pPixmap)
{
---
exa/exa_accel.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index f72a08a..b70222a 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -149,6 +149,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr
- It serves no obvious purpose, yet it directly accesses many fb
symbols.
---
exa/exa_accel.c | 135 +--
1 files changed, 1 insertions(+), 134 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index b70222a..10e7914 100644
---
---
exa/exa_accel.c |7 +--
exa/exa_priv.h|4
exa/exa_unaccel.c | 30 ++
3 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 10e7914..02858f1 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
---
exa/Makefile.am |3 ++-
exa/exa_accel.c | 44 ++--
exa/exa_priv.h |6 +-
exa/exa_render.c| 14 --
exa/exa_unaccel.c | 15 +++
fb/fbcopy_helpers.h |5 +
6 files changed, 69
- It serves no obvious purpose, yet it directly accesses many fb
symbols.
---
exa/exa_accel.c | 135 +--
1 files changed, 1 insertions(+), 134 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index b70222a..10e7914 100644
---
- Compatibility wrappers, if deemed neccesary will come later.
---
fb/Makefile.am |3 +-
fb/fb.h | 37 +-
fb/fb24_32.c|4 +-
fb/fbcopy.c | 342 ++-
fb/fbcopy_helpers.c | 367
---
exa/exa_unaccel.c | 30 +++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d56f589..a521497 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -290,9 +290,14 @@ ExaCheckGetSpans (DrawablePtr
On Mon, Feb 2, 2009 at 5:27 PM, Michel Dänzer mic...@daenzer.net wrote:
On Mon, 2009-02-02 at 16:08 +0100, Maarten Maathuis wrote:
The problem about mangling with fb symbols is that you need to do it
at runtime, that would turn out to be very awkward, not to mention
incorrect. For fallbacks
On Mon, Feb 2, 2009 at 1:52 AM, Ben Gamari bgam...@gmail.com wrote:
On Sun, Jan 25, 2009 at 2:48 PM, Ben Gamari bgam...@gmail.com wrote:
Strangely enough, before I login (in gdm) things seem to behave as
they should. Directly after I login though (even before my own minimal
~/.Xmodmap has been
On Sat, Jan 31, 2009 at 7:37 PM, Brian Rogers br...@xyzw.org wrote:
On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows.
I traced the issue back to an uninitialized condition variable in libX11 xcb
code. So to anyone with mysterious freezes, this may be the fix you need.
On Wed, Jan 28, 2009 at 11:21 PM, Stephane Marchesin
marche...@icps.u-strasbg.fr wrote:
2009/1/28 Florian Lier f...@icram.de:
Okay, new problem:
I tried to insmod the nvdriver...this is the result:
insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module
Any suggestions?
Imagine having tiled pixmaps, that get copied on every map/unmap.
EXA has certain optimisations to avoid migration ping-pong, ofcource
that only applies to drivers using exa's built in memory manager.
My impression is that an optional component, much like the migration
logic in exa, should be
On 12/31/2008 11:42 PM, Timothy S. Nelson wrote:
On Wed, 31 Dec 2008, Jason Gauthier wrote:
So, I?m left wondering how to accomplish this task. Any insight is
helpful!
I'm under the impression that this problem can be solved at both
the X level and the Window Manager level. If no
On 12/22/2008 12:13 AM, Chris Ball wrote:
Hi,
4: /home/fl0/mpx_neu/bin/Xorg(xf86SetGamma+0x37)
See the thread at
http://lists.freedesktop.org/archives/xorg/2008-December/041634.html.
Maarten, any idea when you'll push a fix for this?
Thanks,
- Chris.
Sorry, I thought I had
The placement logic is output driven, and doesn't take panning into
account. So you end up with strange overlap. If dual head + panning was
a goal you might consider fixing this. It doesn't seem trivial to do
from a quick look. On the plus side it's just a xrandr change.
Maarten.
On 12/19/2008 08:42 PM, Carl Karsten wrote:
Maarten Maathuis wrote:
The placement logic is output driven, and doesn't take panning into
account. So you end up with strange overlap. If dual head + panning
was a goal you might consider fixing this. It doesn't seem trivial to
do from a quick
At least the xinerama sizes are not updated to reflect the size of the
panned area. Meaning that your window manager won't consider the entire
panned area as useable space.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
I should swap the reply button for reply to all :-)
On 12/17/2008 10:50 PM, Maarten Maathuis wrote:
On 12/17/2008 09:33 PM, Aaron Plattner wrote:
On Wed, Dec 17, 2008 at 08:05:24AM -0800, Maarten Maathuis wrote:
hw/xfree86/common/Makefile.am |2
hw/xfree86/common/xf86Helper.c |6
These two patches should accomplish the following:
- Usage of Gamma in xorg.conf will be associated with an output and set
on the initial crtc.
(This should work as good as possible for clone modes, eg a non-1.0
gamma will not be overwritten with a standard value)
- Gamma is stored from
The usefulness of it is debatable, i personally don't need it, just
wanted to give a heads up.
Maarten.
libtool: link: ( cd .libs rm -f libxorg.la ln -s
../libxorg.la libxorg.la )
../../doltlibtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc
-DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith
Currently there exist several operations in xrender that are better
off client side or through some other graphic api (imo). Think of
trapezoid rasterisation, gradient rendering, etc. Doing this stuff
client side avoids unforseen migration issues and doesn't create any
false impressions with the
On Fri, Nov 7, 2008 at 5:18 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 14:37:30 -0700, Keith Packard wrote:
On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:
- Apparently there are only 8, 16, and 32bit integers available as
property types. Having ATOMs and FLOATs would
On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote:
Is there any chance to get rid of strings in the protocol/server
altogether and stick to standardised names and properties (in the
form of enums) as much as possible
On Fri, Nov 7, 2008 at 7:38 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Nov 07, 08 18:48:18 +0100, Maarten Maathuis wrote:
On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote:
Is there any chance to get rid of strings
On Fri, Nov 7, 2008 at 7:58 PM, Matthias Hopf [EMAIL PROTECTED] wrote:
On Nov 07, 08 19:44:07 +0100, Maarten Maathuis wrote:
Perhaps now would be the time to standardise on a beheaviour, my
personal opinion is that, the
user should see something that represents the connectors on the back
On Fri, Oct 24, 2008 at 6:27 PM, Maarten Maathuis [EMAIL PROTECTED] wrote:
On Fri, Oct 24, 2008 at 5:57 PM, Rémi Cardona [EMAIL PROTECTED] wrote:
Hi all,
Here's a branch with all the patches that we currently plan on shipping
in Gentoo.
http://www.lri.fr/~cardona/git/xserver.git (server-1.5
On Sun, Nov 2, 2008 at 3:50 AM, Maarten Maathuis [EMAIL PROTECTED] wrote:
Based on the backtrace there are several things that could cause this.
xcb, xrender and cairo are amongst the first that come to mind.
This happens on the GtkDrawingArea - Text test only.
Any idea who i should poke
Based on the backtrace there are several things that could cause this.
xcb, xrender and cairo are amongst the first that come to mind.
This happens on the GtkDrawingArea - Text test only.
Any idea who i should poke?
Maarten.
#0 0x7fc6f74826e3 in __select_nocancel () from /lib/libc.so.6
On Tue, Oct 28, 2008 at 10:37 PM, Keith Packard [EMAIL PROTECTED] wrote:
On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:
- Apparently there are only 8, 16, and 32bit integers available as
property types. Having ATOMs and FLOATs would add semantics, which
could help in some cases.
On Fri, Oct 24, 2008 at 5:57 PM, Rémi Cardona [EMAIL PROTECTED] wrote:
Hi all,
Here's a branch with all the patches that we currently plan on shipping
in Gentoo.
http://www.lri.fr/~cardona/git/xserver.git (server-1.5-branch)
The first 37 patches are backports from git master, basically all
On Sat, Oct 18, 2008 at 11:39 AM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Hi Maarten,
Bilinear and nearest are standard texture unit properties, this should
pose no difficulty for drivers.
Good to know, thanks. I was a bit concerned when mixing both with src and
mask.
As far as the mask
On Sat, Oct 18, 2008 at 12:35 PM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Hi Maarten,
Do you have a test program or at least share the transformation matrix
you're using, because i'm curious why it fails so badly.
Yes I created one, http://pastebin.com/f729a71aa
The testcase works
1 - 100 of 113 matches
Mail list logo
