On Fri, 1 Apr 2011 11:08:47 +1000, Dave Airlie wrote:
> Dave Airlie (4):
> fb: drop defines that aren't used/necessary anymore.
> fb: add back fb defines for driver compat.
> fb: drop comments around 24-bit support.
> fb: cleanup fbChangeWindowAttributes
Merged.
e0a2ad
Hi Keith,
Cyril Brulebois (31/03/2011):
> here are some patches I came up with while I was playing around with
> some XRR* functions.
thanks to Peter, Alan, and Magnus, this series got quickly reviewed.
The following changes since commit 2da3bb5e59db3ed5f689686774dd051766dd39a6:
config: comm
On Fri, Apr 1, 2011 at 10:35 AM, Aaron Plattner wrote:
> On Thu, Mar 31, 2011 at 05:01:20PM -0700, Keith Packard wrote:
>> On Thu, 31 Mar 2011 15:49:36 -0700, Aaron Plattner
>> wrote:
>> > Would this be multiple backing pixmaps like how James envisioned, or
>> > something else? The problem here
Reviewed-by: Peter Hutterer
Reviewed-by: Alan Coopersmith
Reviewed-by: Magnus Kessler
Signed-off-by: Cyril Brulebois
---
man/Xrandr.man |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
v2: Apply suggestion from Magnus, which is far better than the original.
Posting the new patch
These are the initial non-ABI breaking changes. I'll queue up the ones
that nominally break ABI
separately and post further discussion in some cases.
The following changes since commit e0a2ad51dfb7373aa602335490d9666d6101b5ea:
Merge remote-tracking branch 'ajax/xserver-next' (2011-03-30 10:51:2
On Thu, Mar 31, 2011 at 05:01:20PM -0700, Keith Packard wrote:
> On Thu, 31 Mar 2011 15:49:36 -0700, Aaron Plattner
> wrote:
> > Would this be multiple backing pixmaps like how James envisioned, or
> > something else? The problem here is that while pWin may be in the overlay,
> > it may have chi
On Thu, 31 Mar 2011 15:49:36 -0700, Aaron Plattner wrote:
> Would this be multiple backing pixmaps like how James envisioned, or
> something else? The problem here is that while pWin may be in the overlay,
> it may have child windows in the underlay so the driver needs to copy
> those pixels aro
On Thu, Mar 31, 2011 at 7:34 PM, Mark Kettenis wrote:
>> From: Dave Airlie
>> Date: Thu, 31 Mar 2011 16:07:46 +1000
>>
>> From: Dave Airlie
>>
>> This moves ChangeWindowAttributes to mi, and calls a new hook
>> that fb/exa can use to fixup the pixmap properly.
>>
>> I've looked at XAA and it see
>> >> This splits CopyWindow before the exa/fb layers, and uses a
>> >> new interface called PixmapCopyRegion to do the actual copy.
>> >>
>> >> The main point of this is a step towards removing WindowPtr's
>> >> from the interface that drivers see or use.
>> >>
>> >> I've only lightly tested this
On Thu, Mar 31, 2011 at 02:14:03PM -0700, Dave Airlie wrote:
> On Fri, Apr 1, 2011 at 5:05 AM, Aaron Plattner wrote:
> > On Wed, Mar 30, 2011 at 10:21:42PM -0700, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This splits CopyWindow before the exa/fb layers, and uses a
> >> new interface cal
On Fri, Apr 1, 2011 at 5:05 AM, Aaron Plattner wrote:
> On Wed, Mar 30, 2011 at 10:21:42PM -0700, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This splits CopyWindow before the exa/fb layers, and uses a
>> new interface called PixmapCopyRegion to do the actual copy.
>>
>> The main point of this
On Wed, Mar 30, 2011 at 10:21:42PM -0700, Dave Airlie wrote:
> From: Dave Airlie
>
> This splits CopyWindow before the exa/fb layers, and uses a
> new interface called PixmapCopyRegion to do the actual copy.
>
> The main point of this is a step towards removing WindowPtr's
> from the interface t
For fbAdd{Traps,Triangles}() and fbRasterizeTrapezoid() this is just a
matter of adding the image offsets to the trap offsets.
For fbShapes, the story is more complicated:
The recently added pixman API did not allow offsetting
trapezoids. Instead, it would use x_dst and y_dst in such a way that
t
The following patches to pixman and X server respectively should fix
trapezoid rendering to windows. Before drawable offsets were ignored.
Fixing this uncovered that the pixman API I added was pretty broken
because it would always treat the trapezoid coordinates as if they
were in destination spac
Previously, this function would do coordinate calculations in such a
way that (x_dst, y_dst) would only affect the alignment of the source
image, but not of the traps, which would always be considered to be in
absolute destination coordinates. This is unlike the
pixman_image_composite() function wh
On Wed, Mar 30, 2011 at 09:37:21AM -0700, Søren Sandmann wrote:
> From: Søren Sandmann Pedersen
>
> It is not used anywhere else.
>
> Signed-off-by: Soren Sandmann
> ---
[...]
> +pixman_image_fill_rectangles (
> + op, image, (pixman_color_t *)color, nRect,
> + (const pixman_rectan
On 03/30/2011 08:45 PM, Simon Thum wrote:
> On 03/29/2011 03:39 AM, Peter Hutterer wrote:
>> On Mon, Mar 28, 2011 at 04:04:48PM -0400, Chase Douglas wrote:
>>> This allows for masked valuators to be handled properly in XI 1.x
>>> events. Any unset valuators in the device event are set to the last
>
Relative valuator values should not be reported in any future events. If
a relative valuator value is not set in an internal event, set the value
to 0 for XI 1.x valuator events sent over the wire.
Signed-off-by: Chase Douglas
---
dix/eventconvert.c |4 +++-
1 files changed, 3 insertions(+),
It is no longer used in the specs dir.
Remove html from CLEANFILES as it breaks. Make do not clean directories
Remove SUFFIXES as pattern rules are used rather than suffix rules.
Other improvements are possible, the first priority is to move it out
of the specs dir.
Signed-off-by: Gaetan Nadon
-
On 31.03.2011 16:13, Mark Kettenis wrote:
Sorry, but I think that is a bad API. It will lead to confusion
who allocated the buffer.
I would hope the documentation makes this clear. Unfortunately this is
that kind of API where one wants to look at the documentation :).
Also somebody noted t
On 31.03.2011 15:13, Mark Marshall wrote:
There's a (very unlikely) memory leak here.
(getenv_r() == -1 and errno != ERANGE)
Thanks! Can't believe how I missed that. (Or how I missed it in my
valgrind-based tests.)
___
xorg-devel@lists.x.org: X.Org
Dave Airlie writes:
> From: Dave Airlie
>
> these were migrated to mi a while back.
Reviewed-by: Soren Sandmann
Soren
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/li
Dave Airlie writes:
> From: Dave Airlie
>
> From what I can see these functions act the exact same way,
> that is unless I'm missing something subtle.
As far as I can tell, the difference is that fbCopyWindowProc() always
uses GX_COPY and FB_ALLONES, whereas fbCopyNtoN() gets those from the
GC.
No functional changes. Spaghetti code for win! \o/
Signed-off-by: Tiago Vignatti
---
hw/xfree86/loader/loadmod.c | 34 ++
1 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 46ce68b..db
Signed-off-by: Tiago Vignatti
Reviewed-by: Peter Hutterer
Reviewed-by: Nicolas Peninguy
---
This one is with FreePathList addition that Nicolas suggested. Also, based on
Peter's review I generated the next patch, grouping the return code in one
single exit.
hw/xfree86/loader/loadmod.c |6 +
> From: =?UTF-8?q?Erkki=20Sepp=C3=A4l=C3=A4?=
> Date: Wed, 30 Mar 2011 11:53:53 +0300
>
> XauGetFileName has argument char **buffer, which can be used to
> provide an existing buffer for XauGetFileName to store the result
> in. *buffer can be NULL, in which case a newly allocated block of
> memor
> From: Mikhail Gusarov
> Date: Thu, 31 Mar 2011 14:18:13 +0200
>
> Twas brillig at 13:13:23 31.03.2011 UTC+01 when mark.marsh...@csr.com
> did gyre and gimble:
>
> >> +static const char *
> >> +xau_getenv(const char *name)
> >> +{
> >> +size_t len=3D 64;
> >> +char *buff
On Thu, Mar 31, 2011 at 3:57 AM, Erkki Seppala wrote:
> On 30.03.2011 16:18, Dan Nicholson wrote:
>>
>> wrote:
>>>
>>> diff --git a/hw/xfree86/common/xf86Config.c
>>> b/hw/xfree86/common/xf86Config.c
>>> index 7a23253..114bdc3 100644
>>> --- a/hw/xfree86/common/xf86Config.c
>>> +++ b/hw/xfree86/
Twas brillig at 13:13:23 31.03.2011 UTC+01 when mark.marsh...@csr.com
did gyre and gimble:
>> +static const char *
>> +xau_getenv(const char *name)
>> +{
>> +size_t len= 64;
>> +char *buffer = malloc (len);
>> +intrc = 0;
>> +
>> +while (buffer
>> +
On 03/30/2011 02:10 AM, ext Nicolas PENINGUY wrote:
On Tue, 2011-03-29 at 18:12 +0300, Tiago Vignatti wrote:
+++ b/os/utils.c
@@ -1315,6 +1315,7 @@ Popen(char *command, char *type)
/* Ignore the smart scheduler while this is going on */
old_alarm = OsSignal(SIGALRM, SIG_IGN);
i
On 03/30/2011 02:46 AM, ext Nicolas PENINGUY wrote:
On Tue, 2011-03-29 at 18:12 +0300, Tiago Vignatti wrote:
+++ b/hw/xfree86/loader/loadmod.c
@@ -556,6 +558,9 @@ LoaderListDirs(const char **subdirlist, const char
**patternlist)
}
if (listing)
listing[n] = NULL;
+
+F
On 30/03/2011 09:53, Erkki Seppälä wrote:
+static const char *
+xau_getenv(const char *name)
+{
+size_t len= 64;
+char *buffer = malloc (len);
+intrc = 0;
+
+while (buffer
+ && (rc = getenv_r (name, buffer, len)) == -1
+ && errno == ERANGE) {
+
On 03/30/2011 04:18 PM, ext Dan Nicholson wrote:
On Tue, Mar 29, 2011 at 8:08 AM, Tiago Vignatti
wrote:
introduced in e1165632bdfbd720889ed1adf5f7ab338032c0ee.
Actually, it would have been an earlier commit since Peter just moved
this code to a convenience function in that commit. Anyway...
On 30.03.2011 16:18, Dan Nicholson wrote:
wrote:
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 7a23253..114bdc3 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -1459,8 +1459,9 @@ configInputDevices(XF86ConfLayoutPtr layou
> From: Dave Airlie
> Date: Thu, 31 Mar 2011 16:07:46 +1000
>
> From: Dave Airlie
>
> This moves ChangeWindowAttributes to mi, and calls a new hook
> that fb/exa can use to fixup the pixmap properly.
>
> I've looked at XAA and it seems this should work there as well,
> and I'm sure UXA is like
On Don, 2011-03-31 at 15:21 +1000, Dave Airlie wrote:
>
> b) should the hook take Pixmap or Drawable, it probably at least
> needs an assert if it takes drawable and gets passed a window.
>
> c) is PixmapCopyRegion a good enough name?
FWIW, if the name contains Pixmap, it should probably take t
On Thu, Mar 31, 2011 at 5:04 PM, Chris Wilson wrote:
> On Thu, 31 Mar 2011 15:21:42 +1000, Dave Airlie wrote:
>> uxa: left as an exercise for the reader.
>
> What's the best method for checking at compile time which functions to
> implement? Just XORG_CURRENT_VERSION?
> -Chris
If we decide to me
On Thu, 31 Mar 2011 15:21:42 +1000, Dave Airlie wrote:
> uxa: left as an exercise for the reader.
What's the best method for checking at compile time which functions to
implement? Just XORG_CURRENT_VERSION?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
38 matches
Mail list logo
