On Fri, 2010-07-30 at 17:45 -0700, Alan Coopersmith wrote:
> Reported-by: Matt Turner
> Signed-off-by: Alan Coopersmith
> ---
> doc/xml/xmlrules.in |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/doc/xml/xmlrules.in b/doc/xml/xmlrules.in
> index 0d094be..b7fda11
Reported-by: Matt Turner
Signed-off-by: Alan Coopersmith
---
doc/xml/xmlrules.in |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/doc/xml/xmlrules.in b/doc/xml/xmlrules.in
index 0d094be..b7fda11 100644
--- a/doc/xml/xmlrules.in
+++ b/doc/xml/xmlrules.in
@@ -48,10 +48,12
From: Trevor Woerner
The build system already includes the location of the drm header
file (using -I) so the source doesn't need to hard-code the
relative path.
Reviewed-by: Gaetan Nadon
Signed-off-by: Trevor Woerner
---
src/xgi_dri.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-
Signed-off-by: Fernando Carrijo
---
dix/Makefile.am |3 +-
dix/dixutils.c | 79 --
dix/workqueue.c | 166 +++
include/dix.h |2 +
4 files changed, 170 insertions(+), 80 deletions(-)
create mode 100644 dix/
Signed-off-by: Fernando Carrijo
---
dix/Makefile.am |1 +
dix/dixutils.c | 85 --
dix/sleepqueue.c | 173 ++
include/dix.h|2 +
4 files changed, 176 insertions(+), 85 deletions(-)
create mode 100644 di
Signed-off-by: Fernando Carrijo
---
dix/Makefile.am |1 +
dix/callback.c | 322 +++
dix/dixutils.c | 233
3 files changed, 323 insertions(+), 233 deletions(-)
create mode 100644 dix/callback.c
Signed-off-by: Fernando Carrijo
---
dix/Makefile.am|1 +
dix/blockhandler.c | 233
dix/dixutils.c | 145
include/dix.h |1 +
4 files changed, 235 insertions(+), 145 deletions(-)
create m
So, here is the result of my preliminary attempt to bring some order to dix. The
refactoring of the messy dixutils.c into more cohesive files sounded like a good
oportunity for me to experiment with the code, and that's what the following
statistics are about:
[PATCH 1/7] dix: Extract blockhand
Signed-off-by: Fernando Carrijo
---
dix/dixutils.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/dix/dixutils.c b/dix/dixutils.c
index 898dbe5..26a73a3 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -81,22 +81,13 @@ Author: Adobe Systems Incorporated
*
Signed-off-by: Fernando Carrijo
---
include/dix.h | 44 +---
1 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/include/dix.h b/include/dix.h
index 440b9eb..e435456 100644
--- a/include/dix.h
+++ b/include/dix.h
@@ -172,6 +172,13 @@ extern
Signed-off-by: Fernando Carrijo
---
dix/Makefile.am |1 +
dix/dixutils.c | 92
dix/lookup.c| 183 +++
include/dix.h |2 +
4 files changed, 186 insertions(+), 92 deletions(-)
create mode 100644 dix
Tomas Carnecky wrote:
> Fernando Carrijo wrote:
> >
> > I probably didn't understand quite well the reason for what you guys mean by
> > server-side XCB. Google did't help too much either, although I wonder it
> > might
> > be not far from avoiding the burden of maintaining bulky and error-prone
Dne Pá 30. července 2010 16:39:22 Adam Jackson napsal(a):
> On Fri, 2010-07-30 at 10:13 +0200, Marek Vasut wrote:
> > This is useful on PXA framebuffer.
> >
> > Signed-off-by: Marek Vasut
> > ---
> >
> > hw/xfree86/common/xf86Helper.c |3 +++
> > 1 files changed, 3 insertions(+), 0 deletion
On Thu, 2010-07-29 at 16:56 -0400, James Cloos wrote:
> Makes sense.
>
> Reviewed-by: James Cloos
Pushed, thanks.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http:
On Thu, Jul 29, 2010 at 4:41 PM, Adam Jackson wrote:
> ... the continuous stream of
> SIGALRM shows up in strace and thus people report "infinite stream of
> SIGALRM" rather than whatever the bug actually is.
I really hate those SIGALRMs.
Reviewed-by: Patrick E. Kane
Pat
---
On Thu, Jul 2
On 7/30/10 5:22 PM, Fernando Carrijo wrote:
> I probably didn't understand quite well the reason for what you guys mean by
> server-side XCB. Google did't help too much either, although I wonder it might
> be not far from avoiding the burden of maintaining bulky and error-prone code
> by automatica
On Fri, Jul 30, 2010 at 12:22:23PM -0300, Fernando Carrijo wrote:
> I probably didn't understand quite well the reason for what you guys mean by
> server-side XCB. Google did't help too much either, although I wonder it might
> be not far from avoiding the burden of maintaining bulky and error-pron
Daniel Stone wrote:
>
> Fernando Carrijo wrote:
> >
> > Peter Hutterer wrote:
> > >
> > > You'll probably have some fun untangling the various ProcRequestName from
> > > the dix source files (static files, file-specific defines, etc.). And tbh.
> > > I'm not totally convinced that this is worthwile
On Fri, Jul 30, 2010 at 04:09:07PM +0100, Daniel Stone wrote:
> I'm a fan. I've been running this on evdev and synaptics (I did the
> synaptics conversion myself from before you did it, but I assume they're
> pretty much the same), and it doesn't seem to have regressed anything.
On Fri, Jul 30, 2010 at 04:21:16PM +1000, Peter Hutterer wrote:
> As I have mentioned in the past, the input driver API is in need of a
> cleanup. For those easily amused, I recommend going through the input device
> addition process where one can find gimmicks such as the DIX calling the DDX
> whi
On Fri, 2010-07-30 at 16:21 +1000, Peter Hutterer wrote:
> 28 files changed, 252 insertions(+), 606 deletions(-)
That's a nice number.
Reviewed-by: Adam Jackson
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg-dev
On Fri, 2010-07-30 at 10:13 +0200, Marek Vasut wrote:
> This is useful on PXA framebuffer.
>
> Signed-off-by: Marek Vasut
> ---
> hw/xfree86/common/xf86Helper.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf8
On Fri, 2010-07-30 at 10:25 +0800, Huang, FrankR wrote:
> Take an example, we want to support 1024x600, I can add a Modeline to
> xorg.conf. But there is a call to driver named
> "output->funcs->mode_valid" to validate if that resolution should be
> supported. I found this function(lx_output_mode_
Hi,
On Thu, Jul 29, 2010 at 11:58:48PM -0300, Fernando Carrijo wrote:
> Peter Hutterer wrote:
> > I'd say use proto/ for the core protocol handling and put pure protocol util
> > functions into /proto/protoutils.c. The dix util function can then stay in
> > dix/dixutils.c. all the other protocol
Jonathan,
How about the rendering process if the coordinate is negative? How the
driver handle this condition?
By the way, I have done the condition when the coordinate is greater
than source(using modulus first). Is it workaround for all ops? I just
implement the PictOpOver.
T
On Thu, 29 Jul 2010 13:53:39 -0400, Adam Jackson wrote:
> On Wed, 2010-07-28 at 11:35 -0400, Alex Deucher wrote:
> > On Wed, Jul 28, 2010 at 11:29 AM, Alan Coopersmith
> > wrote:
> > > Isn't vm86 even further limited to just those machines running the Linux
> > > kernel, not BSD or Solaris or any
This is useful on PXA framebuffer.
Signed-off-by: Marek Vasut
---
hw/xfree86/common/xf86Helper.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 07f9f0a..724c1a1 100644
--- a/hw/xfree86/common/xf86He
27 matches
Mail list logo