I've been wanting to do this for a while, but the recent work to
eliminate MAXSCREENS has pushed me to get it done sooner rather than
later.
What's the problem with devPrivates?
The biggest issue is that the index space is global. Which is to say
that anyone allocating a private index for any
On Fri, Apr 23, 2010 at 05:39:04PM +0200, Takashi Iwai wrote:
This patch adds the support for Synaptics Clickpad devices.
It requires the change in Linux kernel synaptics input driver, found in
https://patchwork.kernel.org/patch/92435/
The kernel patch is already included in linux-input
On Thu, Apr 29, 2010 at 09:51:58 +1000, Peter Hutterer wrote:
We call NIDR on all devices that make it through the config backend.
Including some that have no driver assigned to them (/dev/input/mouse0 for
example). Those ones then simply get ignored by NIDR, but this should not be
noted as
On Thu, Apr 29, 2010 at 10:12:25 +1000, Peter Hutterer wrote:
For earlier kernels, use the previous hardcoded resolution in place.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Reviewed-by: Julien Cristau jcris...@debian.org
Cheers,
Julien
signature.asc
Description: Digital
On Apr 28, 10 23:59:06 -0700, Keith Packard wrote:
It's possible to adapt to this change with some very small adjustments
in your code; simply replace 'int' in the index variable declaration
with 'DevPrivateKeyRec' and make sure dixRegisterPrivateKey is called
(potentially replacing an
Hi,
On Thu, Apr 29, 2010 at 08:59:06AM +0200, ext Keith Packard wrote:
What's the problem with devPrivates?
Reviewing your proposal made me think if we really need devPrivates mechanism
at all.
It only exists to not change ABI all the time on data structures. But hey, is
this a _real_
Tiago Vignatti wrote:
On Thu, Apr 29, 2010 at 08:59:06AM +0200, ext Keith Packard wrote:
What's the problem with devPrivates?
Reviewing your proposal made me think if we really need devPrivates mechanism
at all.
It only exists to not change ABI all the time on data structures. But hey, is
On Thu, Apr 29, 2010 at 02:06:19PM +0200, ext Matthias Hopf wrote:
I suggest that you have some sort of compile-time define available to
determine the API type - in case some out-of-Xserver part (drivers?)
wants to be backward compatible and support both APIs.
I don't see that in the
On Apr 29, 10 17:50:56 +0300, Tiago Vignatti wrote:
On Thu, Apr 29, 2010 at 02:06:19PM +0200, ext Matthias Hopf wrote:
I suggest that you have some sort of compile-time define available to
determine the API type - in case some out-of-Xserver part (drivers?)
wants to be backward
On Thu, Apr 29, 2010 at 04:43:47PM +0200, ext Alan Coopersmith wrote:
Tiago Vignatti wrote:
Reviewing your proposal made me think if we really need devPrivates
mechanism
at all.
It only exists to not change ABI all the time on data structures. But hey,
is
this a _real_
On Thu, 29 Apr 2010 14:06:19 +0200, Matthias Hopf mh...@suse.de wrote:
On Apr 28, 10 23:59:06 -0700, Keith Packard wrote:
It's possible to adapt to this change with some very small adjustments
in your code; simply replace 'int' in the index variable declaration
with 'DevPrivateKeyRec' and
On Thu, 29 Apr 2010 17:34:47 +0300, Tiago Vignatti tiago.vigna...@nokia.com
wrote:
Reviewing your proposal made me think if we really need devPrivates mechanism
at all.
Yeah, some of my patch was actually to remove devPrivate usage in DIX.
It only exists to not change ABI all the time on
On Thu, 29 Apr 2010 07:43:47 -0700, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
Given that each devPrivate key increased in size from a single int to a larger
structure, it's not that surprising. I'd not expect savings until you've got
a whole bunch of windows, pixmaps, gc's, etc.
On Thu, 29 Apr 2010 18:04:35 +0300, tiago.vigna...@nokia.com wrote:
And when extensions are not used then would be just nil pointers in those
structures, which doesn't cost much.
Right now, we can preserve ABI even across differently built X servers
because the data structures aren't supposed
On Thu, 2010-04-29 at 10:12 +1000, Peter Hutterer wrote:
For earlier kernels, use the previous hardcoded resolution in place.
What will this do if built on 2.6.30 but run on 2.6.29? Do we
know .resolution is always 0 in that case?
- ajax
signature.asc
Description: This is a digitally signed
On Thu, Apr 29, 2010 at 14:22:14 -0400, Adam Jackson wrote:
On Thu, 2010-04-29 at 10:12 +1000, Peter Hutterer wrote:
For earlier kernels, use the previous hardcoded resolution in place.
What will this do if built on 2.6.30 but run on 2.6.29? Do we
know .resolution is always 0 in that
Hi all,
here is an update on my progress:
I have wheel valuator events generated and captured by
a small test program (pscrolltest, see my repository on github:
http://github.com/x-quadraht/pscroll).
The proper valuator resolution is reported (1 unit per old-style scroll click
per default, as
Hi Keith!
I think the important parts of your devPrivates patches will be easier
to review if you rebase on these patches first. I stuck your
signed-off-by on them since they're all extracted from your patch-set,
although I resurrected one comment you deleted from privates.h. If
there's some
From: Keith Packard kei...@keithp.com
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Jamey Sharp ja...@minilop.net
---
include/misc.h |6 ++
include/resource.h |6 --
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/misc.h b/include/misc.h
From: Keith Packard kei...@keithp.com
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Jamey Sharp ja...@minilop.net
---
render/glyph.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/render/glyph.c b/render/glyph.c
index f0f3b19..6b81118 100644
---
From: Keith Packard kei...@keithp.com
For predefined resource types, the offset of the devPrivates field was
already kept in a constant table. The only non-predefined type needing
this treatment was dbeDrawableResType, which is just a magic alias for
RT_PIXMAP.
This patch special-cases looking
From: Keith Packard kei...@keithp.com
In the process, fixes a memory leak in CloseDevice, and an unchecked
memory allocation in InitializePredictableAccelerationProperties.
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Jamey Sharp ja...@minilop.net
---
Xi/exevents.c | 63
From: Keith Packard kei...@keithp.com
Needed as the privates stuff uses the callbacks before they would have
been defined in dix.h
Signed-off-by: Keith Packard kei...@keithp.com
Reviewed-by: Jamey Sharp ja...@minilop.net
---
include/Makefile.am |1 +
include/callback.h | 87
It seems that using xtrans in libX11 results in connection fallbacks that don't
exist in xcb. If I use xscope (built with --disable-xtrans):
Terminal 1 xscope -i5 -o0
Terminal 2 ls -l /tmp/.X11-unix
total 0
srwxrwxrwx 1 jeremy wheel 0 Apr 27 02:25 X0
I am able to connect through xscope using:
On Thu, Apr 29, 2010 at 12:33 PM, Jeremy Huddleston jerem...@apple.com wrote:
It seems that using xtrans in libX11 results in connection fallbacks that
don't exist in xcb. If I use xscope (built with --disable-xtrans):
Terminal 1 xscope -i5 -o0
Terminal 2 ls -l /tmp/.X11-unix
total 0
On Tue, Apr 27, 2010 at 11:50 PM, Ma, Qingyu (GE Healthcare)
qingyu...@ge.com wrote:
I'm developing a system, which uses fvwm as WM. Two fvwm are executed to
implement two separated screens. My process is displayed on one
screen(DISPLAY). It calls XOpenDisplay(NULL) to get one Display
On Apr 29, 2010, at 12:39, Jamey Sharp wrote:
I don't think it makes sense to do it in libX11; we'd have to do
DISPLAY-string mangling there, which seems silly.
I find I'm tempted to say that if the user wants TCP, they darn well
should have asked for it. ;-)
Yeah, I agree... but this
Adam == Adam Jackson a...@nwnk.net writes:
Adam What will this do if built on 2.6.30 but run on 2.6.29? Do we
Adam know .resolution is always 0 in that case?
Earlier kernels always copied sizeof(struct input_absinfo) back to the
user (which didn't used to contain the resolution member) - And
On 04/29/2010 01:20 PM, Keith Packard wrote:
On Thu, 29 Apr 2010 14:06:19 +0200, Matthias Hopf mh...@suse.de wrote:
On Apr 28, 10 23:59:06 -0700, Keith Packard wrote:
It's possible to adapt to this change with some very small adjustments
in your code; simply replace 'int' in the
On Thu, Apr 29, 2010 at 01:05:48PM -0700, Jeremy Huddleston wrote:
On Apr 29, 2010, at 12:39, Jamey Sharp wrote:
I don't think it makes sense to do it in libX11; we'd have to do
DISPLAY-string mangling there, which seems silly.
I don't think we'd have to mangle DISPLAY; just pass
On Thu, 29 Apr 2010 12:24:46 -0700, Jamey Sharp ja...@minilop.net wrote:
Hi Keith!
I think the important parts of your devPrivates patches will be easier
to review if you rebase on these patches first. I stuck your
signed-off-by on them since they're all extracted from your patch-set,
On Thu, 29 Apr 2010 16:42:41 -0400, Eamon Walsh ewa...@tycho.nsa.gov wrote:
So a new rev of devPrivates would involve adding another clause to these
ifdefs.
Right, fortunately the API change is much smaller this time -- it only
affects the initialization of the key and not the usage. Turns out
Here are a few comments about how I see the new devPrivates scheme
working with XSELinux. Note that the current implementation is
sub-optimal when XSELinux is enabled -- the XSELinux private keys get
initialized late in the game and end up increasing the size of all of
the private records with
Josh Triplett wrote:
I find it quite dubious that real applications expect DISPLAY=:0 to
connect to TCP. It certainly violates the principle of least surprise.
But it's what the Xlib standard spec has always required. When no hostname
or transport protocol is provided, Xlib is supposed to
On Thu, Apr 29, 2010 at 03:12:43PM -0700, Alan Coopersmith wrote:
Josh Triplett wrote:
I find it quite dubious that real applications expect DISPLAY=:0 to
connect to TCP. It certainly violates the principle of least surprise.
But it's what the Xlib standard spec has always required. When
On Thu, Apr 29, 2010 at 12:24:49PM -0700, Jamey Sharp wrote:
From: Keith Packard kei...@keithp.com
In the process, fixes a memory leak in CloseDevice, and an unchecked
memory allocation in InitializePredictableAccelerationProperties.
Signed-off-by: Keith Packard kei...@keithp.com
Keith,
I've updated my for-keith branch with two more patches from the list.
One simply changes an error message to an info, the other one fixes linker
errors on scratchbox.
The remaining two have been sitting on this branch for a few days already
anyway.
The following changes since commit
On 04/29/2010 02:59 AM, Keith Packard wrote:
I've been wanting to do this for a while, but the recent work to
eliminate MAXSCREENS has pushed me to get it done sooner rather than
later.
What's the problem with devPrivates?
The biggest issue is that the index space is global. Which is to say
On Wed, Apr 28, 2010 at 4:51 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
We call NIDR on all devices that make it through the config backend.
Including some that have no driver assigned to them (/dev/input/mouse0 for
example). Those ones then simply get ignored by NIDR, but this should
On 04/29/2010 05:48 PM, Keith Packard wrote:
Here are a few comments about how I see the new devPrivates scheme
working with XSELinux. Note that the current implementation is
sub-optimal when XSELinux is enabled -- the XSELinux private keys get
initialized late in the game and end up
On Thu, Apr 29, 2010 at 08:58:16PM +0200, Max Schwarz wrote:
Hi all,
here is an update on my progress:
I have wheel valuator events generated and captured by
a small test program (pscrolltest, see my repository on github:
http://github.com/x-quadraht/pscroll).
The proper valuator
On 4/29/10 8:59 AM, Keith Packard wrote:
Most of this should be fairly obvious, the one exception is probably the
'type' value. This is a fixed enumeration of all possible data
structures holding devPrivates. Let me make that a bit louder.
I AM PROPOSING TO ELIMINATE THE ABILITY TO USE THE DEV
OpenSolaris recently added support for the getifaddrs() API.
Building with that uncovered two compiler issues (one warning, one error)
in the code that was now being built for the first time in our builds:
access.c, line 768: warning: argument #1 is incompatible with prototype:
On Thu, 29 Apr 2010 21:37:18 -0400, Eamon Walsh ewa...@tycho.nsa.gov wrote:
Our mails crossed! I sent a lengthy reply to the original post.
Perfect!
SELinux does use the picture and glyphset privates. Any resource type
with a devPrivates field and a registered offset (returned by
44 matches
Mail list logo
