Hello,
Is there any list of platforms, system libraries and OSes X.org software
should support? Should here means will compile and run aside
occasional breakages if nobody looks upon the particular combination.
I'm looking at cleaning up Xtrans, but I have no idea may I clean up
BSD44SOCKETS,
This seems essential to your approach, so the feasibility of a server
extension (oranything else, but a extension incurs overhead) depends a
fair bit on the dynamics of your gesture customization.
Just specifying what gestures a specific window would be interested in
wouldn't usually be
Hi,
Mikhail Gusarov wrote:
Is there any list of platforms, system libraries and OSes X.org software
should support? Should here means will compile and run aside
occasional breakages if nobody looks upon the particular combination.
I'm looking at cleaning up Xtrans, but I have no idea may I
Twas brillig at 13:00:06 31.03.2010 UTC+03 when vigna...@freedesktop.org did
gyre and gimble:
I'm looking at cleaning up Xtrans, but I have no idea may I clean up
BSD44SOCKETS, SUN_LEN, __SCO__, __UNIXWARE__ etc or not.
TV We can try to keep a mapping between the support we have in the
Twas brillig at 14:28:48 31.03.2010 UTC+07 when dotted...@dottedmag.net
did gyre and gimble:
MG Is there any list of platforms, system libraries and OSes X.org software
MG should support? Should here means will compile and run aside
MG occasional breakages if nobody looks upon the particular
On Wed, Mar 31, 2010 at 01:22:46AM +0200, ext Alan Coopersmith wrote:
Before this fix, the u64 type would not be defined, causing
x86emu/sys.c to fail to build:
sys.c, line 102: syntax error before or at: ldq_u
sys.c, line 102: syntax error before or at: *
Since Keith requested using
On Tue, Mar 30, 2010 at 06:58:28PM +0200, ext Alan Coopersmith wrote:
Isn't removing the headers from xextproto going to break the build of
libXext older Xservers?
(No, you can't delete functions from libXext - we don't break client
library ABI like that. This is why we also no longer
Okay, here are a few more specific questions:
1) The proper way of reporting higher-resolution scrolling in the input driver
would be an additional relative valuator, wouldn't it?
If so, how can I find the right valuator later in X.org to process the events?
Should I post the events using
Signed-off-by: Mikhail Gusarov dotted...@dottedmag.net
---
xinit.c | 91 +++---
1 files changed, 5 insertions(+), 86 deletions(-)
diff --git a/xinit.c b/xinit.c
index 6d354eb..667ad56 100644
--- a/xinit.c
+++ b/xinit.c
@@ -66,18 +66,6 @@
This should be removed together with 49b93df8.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
include/dix-config.h.in |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/dix-config.h.in b/include/dix-config.h.in
index e6e4beb..36497e3 100644
---
On Wed, 2010-03-31 at 07:56 +0200, Rémi Cardona wrote:
Le 26/03/2010 22:30, Gaetan Nadon a écrit :
diff --git a/man/Makefile.am b/man/Makefile.am
new file mode 100644
index 000..9a52ef2
--- /dev/null
+++ b/man/Makefile.am
@@ -0,0 +1,48 @@
+#
+# Copyright 2005 Sun
On Wed, 2010-03-31 at 14:28 +0700, Mikhail Gusarov wrote:
Hello,
Is there any list of platforms, system libraries and OSes X.org software
should support? Should here means will compile and run aside
occasional breakages if nobody looks upon the particular combination.
I'm looking at
Am 31.03.2010 11:45, schrieb Florian Echtler:
This seems essential to your approach, so the feasibility of a server
extension (oranything else, but a extension incurs overhead) depends a
fair bit on the dynamics of your gesture customization.
Just specifying what gestures a specific window
Tiago Vignatti wrote:
We can try to keep a mapping between the support we have in the server
with the one in Xtrans. So variables names and everything else should be
exactly the same on both.
Xtrans is used client side, so supports more platforms than the current X
server does.
--
Mikhail Gusarov wrote:
Is there any list of platforms, system libraries and OSes X.org software
should support? Should here means will compile and run aside
occasional breakages if nobody looks upon the particular combination.
I'm looking at cleaning up Xtrans, but I have no idea may I clean
On Wed, 2010-03-31 at 09:28 -0400, Gaetan Nadon wrote:
On Wed, 2010-03-31 at 14:28 +0700, Mikhail Gusarov wrote:
Hello,
Is there any list of platforms, system libraries and OSes X.org software
should support? Should here means will compile and run aside
occasional breakages if nobody
On Wed, 31 Mar 2010 10:20:23 +0200 rolandc wrote:
Hi,
The -R command line parameter specifies the root directory for
relative path names (see man page)
At the source level, the variable rootDir holds the value of the -R
parameter, but rootDir is never used by xkbcomp
I got this in line 550
On Tue, Mar 30, 2010 at 3:18 PM, Keith Packard kei...@keithp.com wrote:
On Fri, 26 Mar 2010 08:57:57 +1000, Peter Hutterer peter.hutte...@who-t.net
wrote:
I'm a bit torn between the two - evdev feels right but the server is
better.
Let's stick it in the server. That's the piece that needs
On Tue, Mar 30, 2010 at 3:15 PM, Keith Packard kei...@keithp.com wrote:
On Wed, 24 Mar 2010 23:22:35 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
I guess I'd like to
see udev as the default now instead of waiting for the next xserver
series.
udev appears to work for me at least now, with
On Wed, Mar 31, 2010 at 3:53 AM, Vignatti Tiago (Nokia-D/Helsinki)
tiago.vigna...@nokia.com wrote:
Oh yeah, the rationale behind is because no sane application will use this
when we have modern API such DRI2. Besides, xfree86 server has already
deprecated this extension in 1998:
On Wed, Mar 31, 2010 at 4:19 AM, Tiago Vignatti
tiago.vigna...@nokia.com wrote:
This should be removed together with 49b93df8.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
include/dix-config.h.in | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git
On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
But the major point of the InputClass work is that you no longer have
to differentiate between the config backend. The .conf snippet works
for hal or udev. Now you can just install your driver and .conf file
and not
On Wed, 31 Mar 2010 08:31:16 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
They need to build and install a new evdev driver anyway for 1.8 since
the ABI bumped. And this rule will fail if they haven't installed the
evdev driver. I really think these would be better to stay with the
Keith Packard wrote:
On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
But the major point of the InputClass work is that you no longer have
to differentiate between the config backend. The .conf snippet works
for hal or udev. Now you can just install your driver
On Wed, Mar 31, 2010 at 9:49 AM, Alan Coopersmith
alan.coopersm...@sun.com wrote:
Keith Packard wrote:
On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson dbn.li...@gmail.com
wrote:
But the major point of the InputClass work is that you no longer have
to differentiate between the config
On Wed, Mar 31, 2010 at 9:32 AM, Keith Packard kei...@keithp.com wrote:
On Wed, 31 Mar 2010 08:31:16 -0700, Dan Nicholson dbn.li...@gmail.com wrote:
They need to build and install a new evdev driver anyway for 1.8 since
the ABI bumped. And this rule will fail if they haven't installed the
On Wed, 31 Mar 2010 09:49:24 -0700, Alan Coopersmith alan.coopersm...@sun.com
wrote:
So the same patch should remove config/x11-input.fdi since it's no longer
needed in the xorg.conf.d world, right?
Argh. I'm pretty sure we shouldn't be removing files in our 'make
install' phase. I haven't
Nvidia hardware will now default to vesa until an xorg.conf file is
created to set it to nv, nvidia, or nouveau.
We've had reports of displays that fail to autoconfigure because
Xorg tries to use nv, but nv fails when DisplayPort is in use.
Given nvidia's recent announcement deprecating the nv
Remove deprecated acinclude.m4 macro container file
Use separate macro files as per autoconf recommendation
Use the latest macro from GNU (ax) which replaces
the non-gnu version (ac)
This preserves the Autoconf macro AC namespace.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
Makefile.am
Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com
Gaetan Nadon wrote:
Remove deprecated acinclude.m4 macro container file
Use separate macro files as per autoconf recommendation
Use the latest macro from GNU (ax) which replaces
the non-gnu version (ac)
This preserves the Autoconf
From: Alan Coopersmith alan.coopersm...@oracle.com
Date: Wed, 31 Mar 2010 13:38:08 -0700
Nvidia hardware will now default to vesa until an xorg.conf file is
created to set it to nv, nvidia, or nouveau.
The vesa driver only works on i386/amd64. Where does this leave users
of other
This introduced a regression on tinderbox:
http://tinderbox.x.org/builds/2010-03-31-0030/logs/libXfont
On Mar 30, 2010, at 10:19, Gaetan Nadon wrote:
Makefile.am |3 +--
configure.ac |4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
New commits:
commit
Mark Kettenis wrote:
From: Alan Coopersmith alan.coopersm...@oracle.com
Date: Wed, 31 Mar 2010 13:38:08 -0700
Nvidia hardware will now default to vesa until an xorg.conf file is
created to set it to nv, nvidia, or nouveau.
The vesa driver only works on i386/amd64. Where does this leave
On Wed, Mar 31, 2010 at 2:46 PM, Jeremy Huddleston
jerem...@freedesktop.org wrote:
This introduced a regression on tinderbox:
http://tinderbox.x.org/builds/2010-03-31-0030/logs/libXfont
On Mar 30, 2010, at 10:19, Gaetan Nadon wrote:
Makefile.am | 3 +--
configure.ac | 4 ++--
2
On Wed, Mar 31, 2010 at 01:38:08PM -0700, Alan Coopersmith wrote:
Nvidia hardware will now default to vesa until an xorg.conf file is
created to set it to nv, nvidia, or nouveau.
We've had reports of displays that fail to autoconfigure because
Xorg tries to use nv, but nv fails when
Aaron Plattner wrote:
This is an awfully big hammer just to deal with DisplayPort devices, since
the driver still works fine for everybody else. It would be nice to
instead have the server gracefully fall back when PreInit fails instead of
just bailing out, but I can understand if that's too
On Wed, 2010-03-31 at 15:12 -0700, Dan Nicholson wrote:
On Wed, Mar 31, 2010 at 2:46 PM, Jeremy Huddleston
jerem...@freedesktop.org wrote:
This introduced a regression on tinderbox:
http://tinderbox.x.org/builds/2010-03-31-0030/logs/libXfont
On Mar 30, 2010, at 10:19, Gaetan Nadon
Dan Nicholson wrote:
Not quite. The hal backend ignores any devices that don't have the
input.x11_driver key set. We could change that, but it might be better
to keep this behavior for consistency.
So right now, if I start up Xorg from git master on OpenSolaris, where
we still use HAL since I
On Mar 31, 2010, at 18:10, Gaetan Nadon wrote:
Oops, there's a couple issues with that patch.
1. AC_CONFIG_HEADERS does not appear to make the config.h.in template
for you when there are multiple files passed to it. Separating it to
two calls to AC_CONFIG_HEADERS seems to do the trick.
39 matches
Mail list logo
