evdev-2.0.6 error: field `absinfo' has incomplete type
Hello. I'm attempting a build of Xorg 7.4. I've Google'd my way through building Mesa-7.2 and several other places where my build stopped. I've run into an error building xorg-input-evdev-2.0.6 and I'm not able to find any productive information about it. I have Slackware 11.0, gcc-3.4.6, and I'm running Linux 2.6.25.9 which I guess isn't bleeding edge but I don't believe it's too old (?). I downloaded /everything and have downloaded things as-needed from /individual. I'm using build-from-tarballs.sh with the following command-line: ../build-from-tarballs.sh -e -b -m /usr/src/xorg/Mesa-7.2/ /usr/src/xorg/build-7.4/ >& build.log I run this command from /usr/src/xorg/7.4 which contains /everything and selected files from /individual. Here is the error I am receiving: configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating man/Makefile config.status: creating config.h config.status: executing depfiles commands make all-recursive make[1]: Entering directory `/usr/src/xorg/7.4/xf86-input-evdev-2.0.6' Making all in src make[2]: Entering directory `/usr/src/xorg/7.4/xf86-input-evdev-2.0.6/src' /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -I/usr/src/xorg/build-7.4/include/xorg -I/usr/src/xorg/build-7.4//include -I/usr/local/include/pixman-1 -I../src -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c -o evdev.lo evdev.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -I/usr/src/xorg/build-7.4/include/xorg -I/usr/src/xorg/build-7.4//include -I/usr/local/include/pixman-1 -I../src -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c evdev.c -fPIC -DPIC -o .libs/evdev.o In file included from evdev.c:47: evdev.h:85: error: field `absinfo' has incomplete type evdev.c: In function `EvdevReadInput': evdev.c:287: error: `KEY_OK' undeclared (first use in this function) evdev.c:287: error: (Each undeclared identifier is reported only once evdev.c:287: error: for each function it appears in.) evdev.c: In function `EvdevAddAbsClass': evdev.c:767: error: storage size of 'absinfo_x' isn't known evdev.c:767: error: storage size of 'absinfo_y' isn't known evdev.c: In function `EvdevCacheCompare': evdev.c:1040: error: storage size of 'absinfo' isn't known make[2]: *** [evdev.lo] Error 1 make[2]: Leaving directory `/usr/src/xorg/7.4/xf86-input-evdev-2.0.6/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/xorg/7.4/xf86-input-evdev-2.0.6' make: *** [all] Error 2 [EMAIL PROTECTED]:/usr/src/xorg/7.4# I have evdev compiled into the kernel: [EMAIL PROTECTED]:/usr/src/linux-2.6.25.9# grep "EVDEV" .config CONFIG_INPUT_EVDEV=y [EMAIL PROTECTED]:/usr/src/linux-2.6.25.9# I imagine there's a library or header file I'm missing or maybe some relationship I'm not understanding, but I'm not sure which. Thanks. Andy ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Transfer display of active windows remotely
I am active user of X.org and I admire the power and features that X.org provides to the users. I regularly use exported display over an ssh session and operate. I commend the developers for such a wonder piece of software. However, I would like to know one thing as described below. Consider a case where a window has been opened on the local terminal with some user id. After performing a remote login to and exporting the display to that machine using the same user id, is there any way by which the display of that opened window can be transferred to the remote exported display and vice versa? If not possible, then please consider this as a feature request. With Regards, Prasad H. L. --- Prasad H. L. PhD Student (with Dr. Shalabh Bhatnagar), Department of Computer Science and Automation, Indian Institute of Science, Bangalore - 560012 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xf86-input-synaptics: Return correctly on successful property setting
On Fri, Oct 10, 2008 at 09:04:58PM +1100, William Grant wrote: > TRUE was not replaced with Success when all of the other property > handler return codes were. This meant that properties ended up set in > the driver but not the rest of the server. Pushed as db6e631d31d4ffd476ccd105f8adb8d8b4727b29. Thanks for the patch! Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xorg-server 1.5.2
Adam Jackson (6): int10: Remove useless check. int10: Don't warn when scanning for devices we don't have. int10: Fix a nasty memory leak. Revert "Array-index based devPrivates implementation." EDID: Catch monitors that encode aspect ratio for physical size. xserver 1.5.2 Alan Coopersmith (1): Remove usage of mfbChangeWindowAttributes missed in e4d11e58c... Alan Hourihane (1): only build dri2 when DRI2 is enabled Eamon Walsh (1): Array-index based devPrivates implementation. Julien Cristau (1): Fix GKVE with key_code > 255 Kim Woelders (1): xkb: fix use of uninitialized variable. Luc Verhaegen (1): DGA: Fix ProcXF86DGASetViewPort for missing support in driver. Peter Hutterer (2): xkb: fix core keyboard map generation. #14373 xkb: squash canonical types into explicit ones on core reconstruction. Zhenyu Wang (1): Check nextEnabledOutput()'s return in bestModeForAspect() git tag: xorg-server-1.5.2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.5.2.tar.bz2 MD5: 376a1c790f7519f3ab3e047409c659f0 xorg-server-1.5.2.tar.bz2 SHA1: fc8b5ed20af34f504d55a004c35ebacbc603b339 xorg-server-1.5.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.5.2.tar.gz MD5: 047ccab9fc96a2c82b59b83ed203cdea xorg-server-1.5.2.tar.gz SHA1: 7080ce10f2f3c66b59677ee91fe78a4553160164 xorg-server-1.5.2.tar.gz - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Fri, 2008-10-10 at 14:12 -0400, Adam Jackson wrote: > Yeah, that sounds like something I'd say. I am not the release bitch > for 1.6 though. No strong feelings either way on the ABI number, > personally. I'm doing 1.6, and I don't care about ABI numbers either; the only rule we should make is that ABI numbers between two released servers reflect changes in the ABI that have occurred between those releases. For unreleased servers, we shouldn't make any guarantees. However, if you want to bump the number more often than each release, that's fine with me. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Fri, 2008-10-10 at 09:56 -0700, Aaron Plattner wrote: > On Thu, Oct 09, 2008 at 09:34:49PM +1030, Peter Hutterer wrote: > > ABI_XINPUT_VERSION was bumped with the MPX merge, thus 3 is already the > > correct version (server 1.5 has 2, btw.) Should we revert part of this > > patch? > > Sorry about that. I asked Adam if he wanted me to revert that part of it > after I realized I'd done that, and he said something along the lines of, > "nah, integers are cheap." I certainly wouldn't object if you reverted it, > but you should definitely get consensus from the release maintainer du > jour. Yeah, that sounds like something I'd say. I am not the release bitch for 1.6 though. No strong feelings either way on the ABI number, personally. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, 2008-10-09 at 22:52 -0700, Zhenyu Wang wrote:
> diff --git a/hw/xfree86/ddc/xf86DDC.c b/hw/xfree86/ddc/xf86DDC.c
> index 0d86776..ad8feef 100644
> --- a/hw/xfree86/ddc/xf86DDC.c
> +++ b/hw/xfree86/ddc/xf86DDC.c
> @@ -249,6 +249,7 @@ xf86DoEEDID(int scrnIndex, I2CBusPtr pBus, Bool complete)
>
> tmp = xf86InterpretEEDID(scrnIndex, EDID_block);
> }
> +xfree(EDID_block);
>
> if (tmp && complete)
> tmp->flags |= EDID_COMPLETE_RAWDATA;
Nuh-uh. The raw block is stashed in a pointer in xf86MonPtr:
xf86MonPtr
xf86InterpretEDID(int scrnIndex, Uchar *block)
{
xf86MonPtr m;
if (!block) return NULL;
if (! (m = xnfcalloc(sizeof(xf86Monitor),1))) return NULL;
m->scrnIndex = scrnIndex;
m->rawData = block;
/* ... */
return (m);
error:
xfree(m);
return NULL;
}
Reverted in master. xf86MonPtr needs a proper destructor function.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
On Thu, Oct 09, 2008 at 09:34:49PM +1030, Peter Hutterer wrote: > Apologies for not spotting this earlier. > > On Mon, Sep 08, 2008 at 08:51:56AM -0700, Aaron Plattner wrote: > > commit 079625570d51e41569b73b2fd9237eb8f967f408 > > Author: Aaron Plattner <[EMAIL PROTECTED]> > > Date: Mon Sep 8 08:50:52 2008 -0700 > > > > Bump ABI major versions for the TryClientExceptions change from commit > > 883811c. > > > > > > #define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4) > > -#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(4, 1) > > -#define ABI_XINPUT_VERSION SET_ABI_VERSION(3, 1) > > -#define ABI_EXTENSION_VERSION SET_ABI_VERSION(1, 1) > > +#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(5, 0) > > +#define ABI_XINPUT_VERSION SET_ABI_VERSION(4, 0) > > ABI_XINPUT_VERSION was bumped with the MPX merge, thus 3 is already the > correct version (server 1.5 has 2, btw.) Should we revert part of this patch? Sorry about that. I asked Adam if he wanted me to revert that part of it after I realized I'd done that, and he said something along the lines of, "nah, integers are cheap." I certainly wouldn't object if you reverted it, but you should definitely get consensus from the release maintainer du jour. -- Aaron ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Neo 2.0 as a separate keyboard layout or a variant of "de" and handling of "rules" files?
Hi, On Fri, Oct 10, 2008 at 04:00:10PM +0200, Bernd Steinhauser wrote: > Daniel Stone wrote: > > On Sun, Oct 05, 2008 at 03:40:21PM +0200, Bernd Steinhauser wrote: > >> Lately it came up for discussion on the Neo-Layout mailing list, if > >> maybe Neo could be a separate keyboard layout, which might allow it to > >> add variants of it to X.org, too. > >> (For example Neo 1.1, which is currently the Neostyle variant of de > >> could be kept as the neo1.1 variant of Neo, and a One-Hand Neo (usable > >> with one Hand only, similar to ENTI-key++), as well as a Neo 3.0 are > >> planned, plus there are smaller variants for special purpose, too, > >> similar to the "nodeadkeys" variant for de.) > > > > You can have a neo-onehand variant, neo2, neo3, etc (providing it > > actually makes sense to have all these: it's already a pretty marginal > > layout by the looks, so do you need to split it further?). > > I think that gets very complicated and I guess that there won't be any > other variants in the official X.org distribution then (which is a > shame, even if it would be possible). Choice complicates things, yes. > > As I explained to you on IRC, the layout namespace is currently > > locale/language-based. Adding random other variants (especially ones > > that seem to have no particular grounding: they're not > > government-endorsed as is Finland's new Kotoistus layout, and I don't > > believe they ship by default with Windows or OS X?) doesn't help this > > at all. > > No, as far as I know, Windows doesn't ship Neo. > Tbh, I don't get what you are on about with the grounding. I thought > this is an open source project. :) Yes, it is an open source project, but measuring how Windows and OS X do things is a pretty good measure of how people expect their keyboards to behave. > But may I ask you why don't you change the text in the README, if the > addition of layouts, that would not be put under a language namespace, > wouldn't be allowed? Sergey? > > Creation of new layouts is an extremely niche task, and given that we're > > already failing at startup time due to excessive I/O (seeking in > > particular) on XKB files, adding still more probably isn't the way to > > go. Most people would be working on variants of existing layouts, > > assuming that people aren't inventing new locales or languages, so > > they'd need to deal with the package management system in order to not > > get the layout file stomped on upgrades anyway. > > All I can say, is that the current system sucks (sorry for the strong word). It sucks if you're trying to deploy completely new layouts, yes. > The main problem Neo has at the moment is that people have a very hard > time to install it. > There are quite a few people trying it out, that don't really have much > knowledge of computer stuff. > So the best way would be to provide packages for the distributions, > which isn't exactly possible because of file collisions. Right. > So yes, creating new layouts is a niche task, but you might be impressed > at how many people would actually be interested in doing something like > that and how many people would try it out. It's definitely more than > you'd expect. I'm just trying to balance the startup time cost for everyone on the planet, versus helping people create new layouts from scratch; right now, the weight of userbase on the 'new layouts from scratch' side isn't huge. > And especially if it is a nice task, the last thing on earth you should > do is to get in their way, which is exactly what the current system does > and which is a pity. It's not getting in your way for the sake of getting in your way. It's getting in your way because the alternative would be to slow startup down further still, which is unacceptable. I'm happy that you're very interested in keyboard work, and hope the Neo experiment works out well. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Neo 2.0 as a separate keyboard layout or a variant of "de" and handling of "rules" files?
Hi, sorry for the late answer. Daniel Stone wrote: > Hi, > Sergey is the maintainer of the XKB dataset, but I think I can answer > most of these (again), so. > > On Sun, Oct 05, 2008 at 03:40:21PM +0200, Bernd Steinhauser wrote: >> Lately it came up for discussion on the Neo-Layout mailing list, if >> maybe Neo could be a separate keyboard layout, which might allow it to >> add variants of it to X.org, too. >> (For example Neo 1.1, which is currently the Neostyle variant of de >> could be kept as the neo1.1 variant of Neo, and a One-Hand Neo (usable >> with one Hand only, similar to ENTI-key++), as well as a Neo 3.0 are >> planned, plus there are smaller variants for special purpose, too, >> similar to the "nodeadkeys" variant for de.) > > You can have a neo-onehand variant, neo2, neo3, etc (providing it > actually makes sense to have all these: it's already a pretty marginal > layout by the looks, so do you need to split it further?). I think that gets very complicated and I guess that there won't be any other variants in the official X.org distribution then (which is a shame, even if it would be possible). >> Now the main question was if such a change (to add it as a separate >> layout instead of a variant) would actually be allowed. >> There sure would be advantages for the Neo users, but maybe you X.org >> people say that that is a no go and it should be kept in "de", even >> though it doesn't have anything in common with the standard de layout. >> >> The README file doesn't explicitly state, that there may be no >> non-language keyboard layouts, instead it says, that the name must be 5 >> to 8 characters, but maybe in reality you would try to prevent the >> addition of such a layout? > > Yes. > >> So... thoughts on that? > > As I explained to you on IRC, the layout namespace is currently > locale/language-based. Adding random other variants (especially ones > that seem to have no particular grounding: they're not > government-endorsed as is Finland's new Kotoistus layout, and I don't > believe they ship by default with Windows or OS X?) doesn't help this > at all. No, as far as I know, Windows doesn't ship Neo. Tbh, I don't get what you are on about with the grounding. I thought this is an open source project. :) But may I ask you why don't you change the text in the README, if the addition of layouts, that would not be put under a language namespace, wouldn't be allowed? But ok, I accept, even if I think that that solution is far from being optimal, that there is no way it would be accepted as its own layout. >> The next question is about the handling of the rules files. >> It seems that all major desktop environments only read out the base* or >> the xorg* files. >> Now when a user wants to add his own, custom, layout, he has to replace >> these files, which causes problems if he uses a package management >> system, since those files would most likely replaced, if he >> reinstalls/updates the package. >> The alternative is to not modify these files, but then it is not >> possible to use the layout switching capabilities of the desktop >> environment. >> To improve this situation, I would suggest to not use rules *files*, but >> rules *directories*. >> For example, there could be a xorg.d directory instead of the xorg* >> files, which contains the respective .xml and .lst files. >> The difference is, that the actual layout list is not read from a single >> file, but from all files within that directory. >> That would it make possible for a user to place his custom keyboard >> layout into a .xml and a .lst file within that dir and make it available >> for the desktop environment. > > Creation of new layouts is an extremely niche task, and given that we're > already failing at startup time due to excessive I/O (seeking in > particular) on XKB files, adding still more probably isn't the way to > go. Most people would be working on variants of existing layouts, > assuming that people aren't inventing new locales or languages, so > they'd need to deal with the package management system in order to not > get the layout file stomped on upgrades anyway. All I can say, is that the current system sucks (sorry for the strong word). The main problem Neo has at the moment is that people have a very hard time to install it. There are quite a few people trying it out, that don't really have much knowledge of computer stuff. So the best way would be to provide packages for the distributions, which isn't exactly possible because of file collisions. So yes, creating new layouts is a niche task, but you might be impressed at how many people would actually be interested in doing something like that and how many people would try it out. It's definitely more than you'd expect. And especially if it is a nice task, the last thing on earth you should do is to get in their way, which is exactly what the current system does and which is a pity. > I'm sure Sergey would be happy to
[PATCH] xf86-input-synaptics: Return correctly on successful property setting
TRUE was not replaced with Success when all of the other property handler return codes were. This meant that properties ended up set in the driver but not the rest of the server. --- src/properties.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/properties.c b/src/properties.c index dc10888..aa197f2 100644 --- a/src/properties.c +++ b/src/properties.c @@ -505,7 +505,7 @@ SetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop) para->grab_event_device = *(BOOL*)prop->data; } -return TRUE; +return Success; } #endif -- 1.5.6.3 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Xi: check all handlers before applying property changes.
Peter Hutterer wrote:
> something like
>
> --
> RegisterHandler(myHandler, HEAD);
> RegisterHandler(otherHandler, TAIL);
>
> void myHandler(foo) {
>
>CallNextHandler(); /* causes otherHandler to be called */
>return PROP_HANDLED;
> }
> --
>
> Where CallNextHandler calls the handler next in the queue.
> Do I get that right?
Except for the void before myHandler(), yes :)
> If so, a few questions:
> - A handler that registers at the head of the queue, assumes it is before
> other handlers. Thus it has to be aware of other handlers in the first
> place?
Yes, that would be the uncommon case, in which we should be well aware
we're doing something special.
> - Two handlers that place themselves at the head of the queue now both assume
> they are called first?
That's an assumption you shouldn't make. You can make the assumption
that you're called before the others already in.
> - What if the handler order has to be different for each property?
You need two handlers. Keep in mind handlers may well handle different
property sets, so order can't depend on the prop alone.
> - What reason would a handler have for registering at the tail, other than
> that it doesn't care whether it is ever called or not?
Well, be a nice citizen and don't set the house afire :)
A rule of thumb might be: Who does CallNextHandler() may use HEAD. It
should clearly be the exception, not the rule.
I just used HEAD/TAIL since I didn't see a need for more complicated
schemes, like priority.
> At which point - what's the point of this handler anyway?
To simply do its job, just as anyone else. And if it gets 'fired', there
should be a reason for this.
> - if myHandler allows pass-through after changing state, what if otherHandler
> returns an error code?
That's indeed a problem. You shouldn't do it :)
Either you call the rest first, if that's impossible, you should be
prepared to undo stuff.
I think when it gets that complicated, your situation is complicated
anyway. And when stuff is complicated, it's always better to have at
least some control.
Baseline is: Register TAIL, do your job. Or register HEAD, and the
stakes are higher. (I love it when code resembles life)
You also might want to consider this:
http://www.cs.clemson.edu/~malloy/courses/patterns/chain.html
Cheers,
Simon
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
