On Thu, Sep 18, 2008 at 9:22 PM, Keith Packard [EMAIL PROTECTED] wrote:
Owen Taylor has been poking at Composite for a while now and has helped
uncover a couple of interesting corner cases. Here are two patches, the
first is a correctness patch which fixes parent clip recomputation when
On Fri, Sep 19, 2008 at 7:44 PM, Owen Taylor [EMAIL PROTECTED] wrote:
On Fri, 2008-09-19 at 09:06 -0700, Keith Packard wrote:
On Fri, 2008-09-19 at 17:11 +0200, Maarten Maathuis wrote:
Is there a reason why you didn't commit these patches?
Owen hasn't tested the second patch yet. Also, it's
On Sat, Sep 20, 2008 at 11:25 AM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Fri, 2008-09-19 at 22:47 +0200, Maarten Maathuis wrote:
On Fri, Sep 19, 2008 at 10:41 PM, Maarten Maathuis [EMAIL PROTECTED] wrote:
In my experience UploadToScreen is faster than DownloadFromScreen, so
it seems
On Sat, Sep 20, 2008 at 11:28 AM, Maarten Maathuis [EMAIL PROTECTED] wrote:
On Sat, Sep 20, 2008 at 11:25 AM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Fri, 2008-09-19 at 22:47 +0200, Maarten Maathuis wrote:
On Fri, Sep 19, 2008 at 10:41 PM, Maarten Maathuis [EMAIL PROTECTED]
wrote:
In my
On Sun, Sep 21, 2008 at 11:10 AM, Adam Richter
[EMAIL PROTECTED] wrote:
On Fri, 9/19/08, Soeren Sandmann [EMAIL PROTECTED] wrote:
Adam Richter [EMAIL PROTECTED] writes:
I want to suggest a way we could eliminate a
substantial
amount of data copying [...]
[...]
Pixman, the software
On Fri, Oct 3, 2008 at 4:30 PM, Markus Strobl [EMAIL PROTECTED] wrote:
A few weeks ago there were some messages about 1.5.0 being sluggish (1-2
second pauses when switching tabs in firefox, delays in menus appearing etc).
It looked like the cause was identified and tracked to a patch.
I
On Sat, Oct 4, 2008 at 2:12 AM, Markus Strobl [EMAIL PROTECTED] wrote:
Maarten Maathuis wrote:
On Fri, Oct 3, 2008 at 5:50 PM, Markus Strobl [EMAIL PROTECTED] wrote:
If you're referring to the shm pixmap issue in combination with exa,
then that made it in for 1.5.1.
http
On Tue, Oct 7, 2008 at 10:09 PM, Aaron Plattner
[EMAIL PROTECTED] wrote:
On Tue, Oct 07, 2008 at 08:04:52PM +0200, Maarten Maathuis wrote:
These names are supposedly historical, but everyone seems to use them
for the same purpose.
I am aware this may require a few minor changes to (for example
On Tue, Oct 7, 2008 at 8:04 PM, Maarten Maathuis [EMAIL PROTECTED] wrote:
These names are supposedly historical, but everyone seems to use them
for the same purpose.
I am aware this may require a few minor changes to (for example) exa
drivers with driver based memory allocations.
I personally
On Tue, Oct 14, 2008 at 7:35 PM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Hi,
There is ofcource a fallback system, which is pretty much a memcpy.
Ah, I guess that was that memcpy I always saw in moveIn / moveOut ;)
intel has never had an UploadToScreen hook.
Ah interesting, because I saw
On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt [EMAIL PROTECTED] wrote:
On Tue, 2008-10-14 at 16:49 +0200, Maarten Maathuis wrote:
On Tue, Oct 14, 2008 at 4:02 PM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Hello,
I've a use-case where the client uploads 32x32 A8 images to an
256x256x8
On Thu, Oct 16, 2008 at 5:02 PM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Wed, 2008-10-15 at 21:59 +0200, Maarten Maathuis wrote:
On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt [EMAIL PROTECTED] wrote:
Migrating out for a write-only operation is just broken, and is the
thing that should
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
On Sat, Oct 18, 2008 at 12:52 PM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Where do these transformation matrices come from?
They were created by the Java AffineTransform class.
I just dumped it and copied it into the C file.
I basically get an AffineTransformation instance (set by the
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 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.
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 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
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
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
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
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
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
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
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
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
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
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 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?
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 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
---
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
---
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_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
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
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
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
commit 734b23e5982e171031077a2d5d6b5dc2a12e1a70 should fix the problem.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
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
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
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
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
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 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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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:
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
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
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 ?
1 - 100 of 113 matches
Mail list logo
