Hi Pauli,
But some window procedures like the window painting procedures
(ClearToBackground, CopyWindow and compositing) can be accelerated by
hardware.
a. Shouldnt these procedures be implemented by the driver (to get hw
acceleration for these procedures)?
b. Most of the driver implementation
The xf86-video-v4l video driver calls xf86XVQueryOffscreenImages()
function in order to probe for the Xv FOURCC formats supported for
PutVideo ops. However, as this support is deprecated on most of
the modern drivers, a call to this method will cause a crash:
X: ../../../include/privates.h:115: di
>From 58910f286d3944c6ea5124a7ed47b9f827b81136 Mon Sep 17 00:00:00 2001
From: Van de Bugger
Date: Wed, 16 Feb 2011 01:48:08 +0300
Subject: [PATCH setxkbmap] Consistent reporting OOM error.
1. `OOM' macro introduced to check memory allocation error and report it
consistently. In case of error
Of course, I'm talking about it. The implementation is up to you. :-)
On Wed, Feb 16, 2011 at 01:23:06AM +0300, Van de Bugger wrote:
> No. I believe that is wrong approach. I suppose fopen does not crash if
> path too long but returns appropriate error, so we just should check
> result of fopen ca
>From 03567c57b6361325baa49f7238b199ddc7b11cd5 Mon Sep 17 00:00:00 2001
From: Van de Bugger
Date: Wed, 16 Feb 2011 01:28:43 +0300
Subject: [PATCH setxkbmap] Refactoring the help message.
1. Entire help message is printed at once (not line-by-line).
2. Brackets around argumnets of -I option remove
No. I believe that is wrong approach. I suppose fopen does not crash if
path too long but returns appropriate error, so we just should check
result of fopen carefuly, and issue appropriate error message (using
errno and strerror).
On Wed, 2011-02-16 at 02:56 +0500, Alexandr Shadchin wrote:
> Also
Thanks for the suggestion, I did not know about asprintf. I thought it was my
invention. ;-)
Of course, I would like to use asprintf. But rprintf is still required to check
the status returned by asprintf.
I am not sure how to define _GNU_SOURCE macro. I done it with #define in the
source.
O
On Wed, 16 Feb 2011 07:57:34 +1000, Peter Hutterer
wrote:
> InitInput simply initialises all input devices now.
>
> Signed-off-by: Peter Hutterer
Reviewed-by: Keith Packard
--
keith.pack...@intel.com
pgpPY2en7ziax.pgp
Description: PGP signature
Also fopen() can not open path greater than PATH_MAX.
Path still need to verify that it was less than PATH_MAX.
On Wed, Feb 16, 2011 at 12:15:52AM +0300, Van de Bugger wrote:
> From 0aaae5b3c0d6183e2791c30155bae40132a0c779 Mon Sep 17 00:00:00 2001
> From: Van de Bugger
> Date: Tue, 15 Feb 2011 23
InitInput simply initialises all input devices now.
Signed-off-by: Peter Hutterer
---
hw/xfree86/common/xf86Init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
index a1fda54..e664ce4 100644
--- a/hw/xfree86/
On Tue, Feb 15, 2011 at 11:51:16PM +0300, Van de Bugger wrote:
> From 791d2ccef997e85c98a647042e530403465f Mon Sep 17 00:00:00 2001
> From: Van de Bugger
> Date: Tue, 15 Feb 2011 23:46:05 +0300
> Subject: [PATCH setxkbmap] Bug in searching config files fixed.
>
> ---
> setxkbmap.c |2 +-
On 02/15/11 12:48 PM, Van de Bugger wrote:
> On Tue, 2011-02-15 at 10:48 +1000, Peter Hutterer wrote:
>> On Thu, Feb 10, 2011 at 12:00:11AM -0800, Alan Coopersmith wrote:
>>> Signed-off-by: Alan Coopersmith
>>> ---
>>> setxkbmap.c |7 +++
>>> 1 files changed, 3 insertions(+), 4 deletions(
On Wed, Feb 16, 2011 at 12:15:52AM +0300, Van de Bugger wrote:
> From 0aaae5b3c0d6183e2791c30155bae40132a0c779 Mon Sep 17 00:00:00 2001
> From: Van de Bugger
> Date: Tue, 15 Feb 2011 23:55:28 +0300
> Subject: [PATCH setxkbmap] Eliminate limitations on path length.
>
> ...by using dynamically allo
I'd rather see us use the asprintf() interface, so we can just check for it
in libc in configure and use it directly when possible, with a fallback for
older systems, than invent a rprintf() API that doesn't match common usage.
There's a bunch of examples of asprintf() recently committed to variou
>From 0aaae5b3c0d6183e2791c30155bae40132a0c779 Mon Sep 17 00:00:00 2001
From: Van de Bugger
Date: Tue, 15 Feb 2011 23:55:28 +0300
Subject: [PATCH setxkbmap] Eliminate limitations on path length.
...by using dynamically allocated buffers. No need in PATH_MAX,
MAXPATHLEN. No more "Path too long" er
>From 791d2ccef997e85c98a647042e530403465f Mon Sep 17 00:00:00 2001
From: Van de Bugger
Date: Tue, 15 Feb 2011 23:46:05 +0300
Subject: [PATCH setxkbmap] Bug in searching config files fixed.
---
setxkbmap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/setxkbmap.c
On Tue, 2011-02-15 at 10:48 +1000, Peter Hutterer wrote:
> On Thu, Feb 10, 2011 at 12:00:11AM -0800, Alan Coopersmith wrote:
> > Signed-off-by: Alan Coopersmith
> > ---
> > setxkbmap.c |7 +++
> > 1 files changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/setxkbmap.c b/setxkbm
On 02/15/2011 12:27 PM, Daniel Stone wrote:
> When delivering an event to a device grabbed with SyncBoth,
> DeliverGrabbedEvent walks the device tree looking for associated devices
> to freeze them. Unfortunately, it froze all devices instead of just the
> paired device, and the previous fix in 4f
On Tue, Feb 15, 2011 at 8:28 AM, Cyril Brulebois wrote:
> Hi Warner,
>
> Warner Losh (14/02/2011):
>> I'm mentioned this several times now: Get me a spec for what Linux
>> udev provides, and what services are needed, and I'll make a
>> compatible implementation on FreeBSD.
>
> as far as X is conc
Hi Warner,
Warner Losh (14/02/2011):
> I'm mentioned this several times now: Get me a spec for what Linux
> udev provides, and what services are needed, and I'll make a
> compatible implementation on FreeBSD.
as far as X is concerned, see Dan's reply to my first mail:
http://lists.debian.org/d
On Mon, Feb 14, 2011 at 08:43:08AM +0100, Matthieu Herrb wrote:
> On Sun, Feb 13, 2011 at 04:44:35PM -0800, Alan Coopersmith wrote:
> > On 02/13/11 12:51 PM, Matthieu Herrb wrote:
> > > $< is not allowed in explicit rules.
> >
> > Solaris make has the same limitation, but since I have to use gnu m
Hi Keith,
These should be in 1.10.
The following changes since commit ea1ffd3e60bdcedbec5a6f28929f8677bf45d450:
Merge remote branch 'whot/for-keith' (2011-02-02 15:19:55 -0800)
are available in the git repository at:
git://people.freedesktop.org/~jcristau/xserver for-keith
Julien Cristau
Some event types (notably Expose and GraphicsExpose) require multiple
events, a la XI 1.x. Bring the EventToCore API in line with EventToXI's
and allow it to generate multiple events.
Signed-off-by: Daniel Stone
---
dix/eventconvert.c | 37 -
dix/events.c
Rename the return mask values for EventIsDeliverable:
* CORE_MASK -> EVENT_CORE_MASK
* XI_MASK -> EVENT_XI1_MASK
* XI2_MASK -> EVENT_XI2_MASK
* DONT_PROPAGATE_MASK -> EVENT_DONT_PROPAGATE_MASK
And don't undef them in dix/events.c, since they're supposed to be
global.
Signed-off-by
When a client has selected for Xi 1.x DeviceStateNotify events, they
should receive them when a DeviceFocusIn event is generated. The code
to do this was there, but an incorrect test (checking the passed-in Xi 2
event type rather than the event's Xi 1 event type) meant they were
never being sent.
Instead of switching on the event filter to determine delivery, use the
event type instead.
Signed-off-by: Daniel Stone
---
dix/events.c | 44 +---
1 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 2b6f9c0.
When delivering an event to a device grabbed with SyncBoth,
DeliverGrabbedEvent walks the device tree looking for associated devices
to freeze them. Unfortunately, it froze all devices instead of just the
paired device, and the previous fix in 4fbadc8b17237f3c would still break
if the same client
CheckDeviceGrabs will activate a passive grab for KeyPress and
ButtonPress events. GrabInfoRec::activatingKey contains the keycode
which activated the passive grab, so we can deactivate it later in
ProcessOtherEvents.
Previously, CheckDeviceGrabs relied on its callers to set
activatingKey, which
Hi,
The following series fixes a couple of bugs I found by inspection, and
shuffles a few things around in preparation for expanding InternalEvent
usage. There's a few more patches in my people.fd.o tree, but I'm going
to wait until I've had more time to test them before I push them.
Cheers,
Dani
On Tue, Feb 15, 2011 at 09:18:36AM +0200, Pauli Nieminen wrote:
> On 14/02/11 21:06 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 08, 2011 at 11:42:54PM +0200, ext Pauli wrote:
> > > From: Pauli Nieminen
> > >
> > > If client disconnects and new client gets same id DRI2 events may end to
> > > wron
On Tue, Feb 15, 2011 at 4:54 AM, kumar vemuri wrote:
> Hi,
>
> In most of the reference DDX driver implementations, the Pixmap procedures
> (CreatePixmap, etc) are being implemented by the driver and also are getting
> populated in the ScreenRec structure by the driver. But none of the Window
>
On Tue, Feb 15, 2011 at 08:24:37AM +0530, kumar vemuri wrote:
> In most of the reference DDX driver implementations, the Pixmap
> procedures (CreatePixmap, etc) are being implemented by the driver and
> also are getting populated in the ScreenRec structure by the driver. But
> none of the Window
32 matches
Mail list logo