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 t
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
On Wed, 2010-03-31 at 15:12 -0700, Dan Nicholson wrote:
> On Wed, Mar 31, 2010 at 2:46 PM, Jeremy Huddleston
> 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:
> >
>
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 t
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
On Wed, Mar 31, 2010 at 2:46 PM, Jeremy Huddleston
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 files changed, 3
Mark Kettenis wrote:
>> From: Alan Coopersmith
>> 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
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 8e84687b26be6e
> From: Alan Coopersmith
> 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 architectures? Quite a
Dan Nicholson wrote:
On Wed, Mar 31, 2010 at 3:53 AM, Vignatti Tiago (Nokia-D/Helsinki)
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:
http://www.xfre
Reviewed-by: Alan Coopersmith
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 macro AC namespace.
>
> S
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
---
Makefile.am |2 ++
ac
Reorder the initialization section at the top of the file.
Signed-off-by: Gaetan Nadon
---
configure.ac | 36 ++--
1 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/configure.ac b/configure.ac
index 29aa0f2..9a4564b 100644
--- a/configure.ac
+++ b
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
On Wed, 31 Mar 2010 09:49:24 -0700, Alan Coopersmith
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 noticed any ill effects f
On Wed, Mar 31, 2010 at 9:32 AM, Keith Packard wrote:
> On Wed, 31 Mar 2010 08:31:16 -0700, Dan Nicholson 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 the
On Wed, Mar 31, 2010 at 9:49 AM, Alan Coopersmith
wrote:
> Keith Packard wrote:
>> On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson
>> 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
>>>
Keith Packard wrote:
> On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson 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 fil
On Wed, 31 Mar 2010 08:31:16 -0700, Dan Nicholson 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
> drivers. Do you also wa
On Wed, 31 Mar 2010 08:29:32 -0700, Dan Nicholson 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 have to worrry a
On Wed, Mar 31, 2010 at 4:19 AM, Tiago Vignatti
wrote:
> This should be removed together with 49b93df8.
>
> Signed-off-by: Tiago Vignatti
> ---
> 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
On Wed, Mar 31, 2010 at 3:53 AM, Vignatti Tiago (Nokia-D/Helsinki)
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:
>
> http://www.xfree86.org/3.3.6/i
On Tue, Mar 30, 2010 at 3:15 PM, Keith Packard wrote:
> On Wed, 24 Mar 2010 23:22:35 -0700, Dan Nicholson 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 nothing other than
> the t
On Tue, Mar 30, 2010 at 3:18 PM, Keith Packard wrote:
> On Fri, 26 Mar 2010 08:57:57 +1000, Peter Hutterer
> 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 to
> differentiate between hal
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
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 breakag
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
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.
--
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 speci
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 looki
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
This should be removed together with 49b93df8.
Signed-off-by: Tiago Vignatti
---
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
--- a/include/dix-config.h.in
+++ b/
Signed-off-by: Mikhail Gusarov
---
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 @@ in this Software without
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 xf86Pos
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 long
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 usi
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 partic
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 th
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
> >> 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
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,
41 matches
Mail list logo
