Re: 4.3.902 bug report
On Sun, 2003-12-21 at 08:04, Kean Johnston wrote: Which compiler are you using ? CARD32 is typedef'd to an unsigned gcc 2.95.3. The warning is not wrong though. It simply warns that we are passing argument 1 to function pmd5_hash() and add_entropy() from an incompatible pointer type. A CARD32 * is not the same as an unisgned int *, even though CARD32 is typedef'ed to an unsigned int. The typedef introduces a new type and it is pedantically different. pedantic Typedefs are generally considered not to introduce new types in C. Likely the compiler is warning because CARD32 is typedef'ed to unsigned long not unsigned int on your system. (long and int *are* distinct, even when they have the same width.) /pedantic Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree CVS Blocker Bugreport
On Thu, 2003-10-30 at 03:14, Ali Akcaagac wrote: Please bear with me abusing the ML for reporting this bug. But It's quite seldom that I report anything to XFree thus I didn't wanted to open yet another bugzilla account for this. I would like to ask whether it is possible for you developers to track this issue down in the current XFree CVS HEAD which is a nagging bugger when using GTK+ 2.3.0 and leads applications to crash. The bug is inside XFree for quite some months now and is probably related to 'miscompute network buffer pointers' or something. I am no XFree or Xlib specialist so I am not in the position to track this down better (I am only a developer hacking some GTK/GNOME apps more or less). Thus I searched on the net and found two bugreports that leads to the same issue: http://pdx.freedesktop.org/pipermail/xlibs/2003-October/04.html http://bugzilla.gnome.org/show_bug.cgi?id=118436 http://bugzilla.xfree86.org/show_bug.cgi?id=839 Has the minimal 6 character patch. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: using externally built libs (Xcursor, Xrender, Xft)
On Thu, 2003-09-25 at 20:56, Warren Turkal wrote: Here is another patch from the Debian project. It comes in 3 parts. I basically allows XFree86 to build using an externally built libs. http://bugs.xfree86.org/show_bug.cgi?id=741 It wouldn't let me classify into multiple libraries...so I just associated it with other. I don't see how building against an external Xrender/etc works, since those libraries depend on libX11; to avoid a dependency loop, we copy the libraries into the X11 tarball and do various munging. Fixing that isn't really possible without splitting up of main tarball. (Better external fontconfig support would be appreciated, however) Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
On Wed, 2003-09-24 at 12:30, Craig Ringer wrote: Should the /usr/X11R6 heirarchy be added to pkgconfig's default config? Perhaps it would be better if pkg-config provided an opaque way to add directories to the search paths. Does it have a config file in /etc. My Debian system doesn't have anything in /etc for pkg-config. It understands the PKG_CONFIG_PATH environment variable, but I'm not sure it has any config file. A polite request to the pkg-config people to add /usr/X11R6/lib/pkg-config (or whatever) to the default might not go astray, as if X were to begin using pkg-config it would be a common place to look. See discussion the xdg-list archives over the last week or so https://listman.redhat.com/archives/xdg-list/ the approximate conclusion that has been arrived there is that some sort of $sysconfdir/pkg-config.conf file is the right approach, though someone still needs to implement that. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
On Sun, 2003-09-21 at 22:38, David Dawes wrote: On Sun, Sep 21, 2003 at 09:06:43PM -0500, Warren Turkal wrote: David Dawes wrote: I think you have your perspective backwards. Autotools is supposed to handle system differences for the software package, not impose requirements on the underlying system. Autotools do not require pkg-config. It just makes autotools significantly easier to implement in a portable way for libs. X libraries are already installed on countless systems, and they're not going to magically acquire .pc files just because you say you need them. If an autotooled package requires them, the autotooled package is broken. Autotools do not require them...pkg-config just makes autoconf work a lot easier. I could write custom autoconf macros that test for Xrender in common locations, or we could put pkg-config support in and it would not have to guess. The .pc files tell it where to find the libs. I'd love to see your time machine. Dunno how else you're going to avoid writing those custom autoconf macros :-). Well, to some extent, I think the goal is that in 5 years people aren't *still* saying if you had a time machine, and could put those .pc files in 5 years ago... It's also possible to make macros that have fallback checks simpler and more reliable for systems that *do* have the .pc files, and to fall back to the old methods only where the .pc files don't exist. Finally, while autoconf includes macros for -lX11, there are lots of other libraries that XFree86 ships where there are no standard autoconf macros (libXv, libXxf86misc, and so forth.) .pc files for these would have considerable utility. One more thing to mention is that pkg-config is often useful when compiling on the command line or in one off make files. gcc -o mytest mytest.c `pkg-config --libs --cflags x11` Is, if not easier to type, easier to remember, than specifying the flags (-L/usr/X11R6/lib -lX11 -lm, usually, for XFree86, if it's installed in the standard location) manually. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Enum windows in order to get process id
On Tue, 2003-09-16 at 13:50, Tim Roberts wrote: On Tue, 16 Sep 2003 03:56:36 -0500, theoharis tsenis wrote: i am new in Xwin programming. I made an enumwindow function. For each visible window i get a Window structure. My main consern is to get the process id of the window and i am puzzled the way i should terminate that process if necessery. To elaborate on Mark's response, the REASON you cannot get a process ID for a given window is that, in the X world, that window might have been generated by a program on an entirely different computer, running an entirely different operating system, across the network. That being said, the ICCCM defines the WM_CLIENT_MACHINE property: WM_CLIENT_MACHINE(STRING) = poincare.devel.redhat.com and the freedesktop.org WM spec defines the _NET_WM_PID property: _NET_WM_PID(CARDINAL) = 23397 So, if the toolkit that creates the window supports these specifications, you can find out the client machine and process ID. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, 2003-08-10 at 19:05, Carsten Haitzler wrote: The current plan for addressing the second two is to do it as part of the 'libic' library so the same code can be used in the X server and in the software fallbacks for Cairo. I think a couple of people have taken a look at doing that optimization work, though I'm not sure if anybody is working on it actively at this time. libic? hmmm part of Xr? or Xc? i have handy code to optimize paths when you need it. For now it happily lurks at the bottom of all my own software rendering pipelines... :) It used to be libXr depends on libXc depends on libic. But libXr and libXc have now been merged and renamed to 'Cairo'. The hope is certainly that we can pool knowledge to get the ultimately fast code for each platform in libic without having to do it over and over again in different places; right now, everybody has there own favorite set of routines, and as fun as it is to hand-tweak MMX and squeeze out a few extra million pixels per second (I have my own set of such routines around somewhere), it's not really efficient... Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
On Wed, 2003-08-13 at 08:56, Ivan Pascal wrote: With the actual mode of implementation (not using the Lock modifier), yes, you don't have the problem of it affecting non-alphabetic keys. I would have the problem with it affecting non-alphabetic keys if I didn't use the Lock modifier. There is not such problem because the actual mode of implementation does use the Lock modifier. I tried to explain it in my replies to Pablo. I think you just have to realize that XKB is too complex for anybody to fully understand it without spending several hours a week on it. :-) However, you do have the problem that applications can't tell that the level change was produced by the caps-lock key. Which sometimes is useful information. For instance, the obvious fix for: http://bugzilla.gnome.org/show_bug.cgi?id=115384 which is to strip out the Lock modifier before checking for accelerator matches, won't work. I am sorry for the repeating. Did you try it before writing this? You really don't have to be rude. Just tell me to try it. I made the assumption that if I had read the relevant Xlib XKB code and read the relevant rules file, I would have some idea what was going on. A dangerous assumption when XKB is involved. Going back and rereading your mail and rereading the code, I see how it's being accomplished via the magic of consumed modifiers. But really, I don't feel bad about not figuring that out the first time. And I don't feel bad about not doing a bunch of practical experimentation. Life's too short. Too many other bugs to worry about. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
On Tue, 2003-08-05 at 14:32, Ivan Pascal wrote: Owen Taylor wrote: On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: Now Turkish keyboard users just have to set XkbOption caps:shift. With that option Xlib doesn't use 'internal capitalization' but CapsLock key acts as 'locking Shift' (but can be canceled by Shift key). It solves the problem. I don't think that this is a particularly good way to handling things. Using caps:shiftproduces all sorts of strange behavior - for example, the number keys will give their shifted variants. I risk to seem impolite but did you try this option before making such assertion? If you tried you would notice that it is not true. I had the made the assumption that caps:shift did the classic X thing and changed the keysym to be Shift_Lock rather than Caps_Lock. With the actual mode of implementation (not using the Lock modifier), yes, you don't have the problem of it affecting non-alphabetic keys. However, you do have the problem that applications can't tell that the level change was produced by the caps-lock key. Which sometimes is useful information. For instance, the obvious fix for: http://bugzilla.gnome.org/show_bug.cgi?id=115384 which is to strip out the Lock modifier before checking for accelerator matches, won't work. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, 2003-08-10 at 03:22, Carsten Haitzler wrote: On Sat, 9 Aug 2003 22:07:21 -0700 (PDT) Mark Vojkovich [EMAIL PROTECTED] babbled: On Sun, 10 Aug 2003, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers(as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? The NVIDIA drivers fall back to software if the source or mask have any transform. really? very interesting as i'm getting my own mmx asm bleding routines blending @ 32bpp being 35 times faster than xrender (blending at 1:! scaling, no transform, nearest filter for scaling). display is 24bpp (src picture is 32bpp, with alpha, component alpha set, repeat set to true, dither true). i am not sure.. but a 35 TIMES speed difference with software being the faster... sounds wrong to me. If you are getting 35x faster, it probably means that you are hitting a code path not accelerated in the NVIDIA drivers... one common case where this used to happen is if the *source* is in video ram. I know Mark has been working on fixing this (at least as part of the XAA rewrite for XFree86 5, but it may still be a limitation of the current nvidia drivers. Making the source a SHM pixmap can be a big win, because it forces it into system ram. Or it might be the repeat, or dither. As for why your software fallbacks are 35x faster than the render fallbacks, there are three causes, in rough order of importantance. - The image is being pushed/pulled over the bus (AGP bus, likely) both ways by the video card instead of having 2 PCI transactions per pixel. The nvidia drivers in particular do a good job at optimizing GetImage. - Special casing of the particular formats in your compositing routines. The RENDER code is very general, and very slow. - MMX acceleration The current plan for addressing the second two is to do it as part of the 'libic' library so the same code can be used in the X server and in the software fallbacks for Cairo. I think a couple of people have taken a look at doing that optimization work, though I'm not sure if anybody is working on it actively at this time. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CapsLock behaviour and Turkish keyboard
On Tue, 2003-08-05 at 08:55, Ivan Pascal wrote: Hi, I see keyboard topics are being discussed right now... there is long standing problem with the CapsLock and turkish keyboard that would be nice to have fixed. Yes. There *was* such problem and it was discussed year ago. :-) (I don't remember but I was sure you took part in that discussion.) Now Turkish keyboard users just have to set XkbOption caps:shift. With that option Xlib doesn't use 'internal capitalization' but CapsLock key acts as 'locking Shift' (but can be canceled by Shift key). It solves the problem. I don't think that this is a particularly good way to handling things. Using caps:shiftproduces all sorts of strange behavior - for example, the number keys will give their shifted variants. The Turkish user might well wonder why everybody else gets a useful caps lock key, while they have this monstrosity. It should be possible in Xlib's code for handling lock == Caps_Lock to simply special case this; if the lower case key is 'i', then check to see whether the key in the second level is 'I' or 'Idotabove', and act accordingly. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Change of behavior of shift+numpad arrow keys (withoutnumlock)
On Mon, 2003-08-04 at 09:10, Egbert Eich wrote: Bugzilla 558 requests to change the behavoir of shift+numpad arrow keys In reasonable X GUIs (GNome/KDE), shift + regular arrow key selects text. But if i press shift + numpad arrow key, i get numbers! So the current XKB behavior makes Shift kind of like the lockless version of Numlock, which is insane, IMHO. the numpad keys are *arrow* keys (unless numlock is turned on) by definition. Shift should have no effect on them. The current behavior is contrary to what Windows users are used to (and highly annoying for this reason). I see no reason to have a different behaviour to Microsoft in this regard (seeing as though this can potentially piss off 90+% of users), apart from the sake of wanting to be different (which is not a good reason). Instead of a being just a whinger, I provide this patch (please apply with -l) This requests sounds reasonable so I would like to find out if somebody has a strong opinion on this issue. If not I will commit the supplied fix. Well, the current setup is compatible with the non-XKB behavior documented in section 12.7 of the Xlib reference manual. So, there are some compatibility concerns about changing it. You could imagine an application that documented shortcuts with respect to the current system. I don't think that is necessarily a killer objection if there are significant usability advantages to a different mapping, but what seems to be missing above (and in the bug report) is more details of *why* this behavior is annoying. While it may be unexpected, it doesn't seem to me that pressing shift+KP_whatever is something you would do by accident. And I wouldn't expect many people to have learned to use shift+kp_arrows for extending the selection. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XSetInputFocus + XEmbed + Keyboard events to the wrong windows
On Thu, 2003-07-31 at 09:29, Andreas Aardal Hanssen wrote: Hello, there. I'm currently working on an implementation of XEmbed, and have run into a problem with XSetInputFocus. Please redirect me to the right forum if this was posted to the wrong place. What I'm troubled with is Keyboard Focus, described here: http://www.freedesktop.org/standards/xembed-spec/0.5-html/ar01s03.html Note that [EMAIL PROTECTED] would likely be a better place for this mail, since that's the normal place for discussing the freedesktop.org specifications. [...] XSetInputFocus(). focusProxy- * |A | |__ | | |B | | | |__| | || || So I have a window A with a focusproxy child window, measuring 1x1 at -1,-1, and I call XSetInputFocus on this focusproxy with RevertToParent. - To emphasize, B isn't a child window of A (in XEmbed, the embedder). B is a window created by a seperate application, which has called XReparentWindow to reparent B into A. So B is the XEmbed client. B actually fully covers A, so the size difference in my art is just for clarity. I assume you mean B wasn't created as a child window of A. If it has been successfully reparented into A, it will then be a child window of A. The problem is that the focusproxy receives all keyboard events only if the mouse pointer is outside window A (the embedder window). On or outside the window decorations, doesn't matter as long as the mouse pointer is outside window A. If the mouse pointer is inside window A, window B gets the keyboard events directly. If I move the mouse pointer out of the window A again, my focusproxy gets keyboard events again. Are you sure that the focusproxy window is getting the events, not window A? It sounds very much to me like you simply didn't manage to get the focus set to the focusproxy window. Note that the focus has to be set to the focusproxy window each time that the toplevel gets focused; this requires participating in the WM_TAKE_FOCUS protocol as described in the ICCCM. Installing an x11 event filter gives me the EnterNotify and LeaveNotify for A and B as I cross the border of window A. I also get a KeymapNotify, and I guess (having no clue really) that this is X11's way of telling me that A isn't getting keyboard events anymore. No, keymap notifies shouldn't be related. So my question is this: Is the XEmbed protocol broken, is my X11 server broken, or is my code broken, and in which way. Definitely your code is broken; the setup in XEMBED works fine for GTK+, for KDE, on a wide ranger of different X servers. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -fexeptions in library build rules with callbacks
On Wed, 2003-07-16 at 13:11, Egbert Eich wrote: We have a bug report at http://bugs.xfree86.org/show_bug.cgi?id=503 that suggests that when building libraries with callbacks using gcc the option -fexeptions should be used. It enables C++ programs to catch the exceptions. I've talked to a gcc expert and he says that using this option is sane. It adds unwind information and on some targets it supresses a few optimizations that break unwinding, however these optimizations are no big deal. In statically linked binaries the exception tables should automatically be removed if the binary does not use them. Is this useful if the libraries don't properly handle exceptions being thrown through them? I'd really suspect that most/all places where there are callbacks in the X libraries they will leak memory / corrupt state / otherwise misbehave if you throw an exception from a callback and catch it in the surrounding code. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Hardware cursor not on desktop?
On Thu, 2003-07-10 at 19:04, Chris Edgington wrote: Still working on this siliconmotion upgrade for the 0730 chipset. Running RH9, latest xfree code from cvs. Got hardware cursor working but I'm only getting hardware cursor-related calls in certain scenarios. If I start gimp - hardware cursor is used for the custom cursors while over an image. Other apps that use custom cursors seem to result in hardware cursor calls . but when the cursor goes over the desktop (or the menus, etc.) HideCursor is called and I can only assume that a software cursor is now in use. Is this expected - or should hardware cursor be used at all times? Unless your hardware supports alpha-blended full color cursors, the only place a hardware cursors are going to be used are places where the current cursors theme doesn't have a cursor to replace the old X bitmap cursor. (Perhaps you've noticed the difference in appearance between the cursors that get sent to the hardware and the other cursors) Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Get pid of a window??
On Wed, 2003-06-25 at 06:02, Martin Ehmsen wrote: Hi... I have a question (I can't seem to find the answer anywhere, so here goes): Given a Window (ex. Window w, from an event or somewhere else) is it possible to determine the program that owns that window? To be exact, I want the pid of the process owing the window. If the app suports the recent window manager spec, you can look for the _NET_WM_PID property. Make sure to check WM_CLIENT_MACHINE as well. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: device name in XListInputDevices
On Wed, 2003-06-25 at 04:13, Egbert Eich wrote: An interesting question appeared on bugzilla (ID #412). According to the man page of XListInputDevices() the string returned in the name field of the XDeviceInfo struct is supposed to be one listed in XI.h. In reality it is a name specified by the driver. The same is true for the type (which according to the XInput Proto specs is supposed to be an atom for one of the predefiend device types) which however is assigned an Atom according to the driver-specified type. Returning a device type both as an atom and as a string doesn't seem to make sense. I would assume that type should be a predefined 'type' to allow an application to identify what kind of devices exist while 'name' should identify the type and model of the device uniquly and should therefore be a string choosen by the driver. I assum that this was the intention. Looking at the code in common/xf86Xinput.c: local-atom = MakeAtom(local-name, strlen(local-name), TRUE); AssignTypeAndName (dev, local-atom, local-name); It should however have been: local-atom = MakeAtom(local-type_name, strlen(local-name), TRUE); AssignTypeAndName (dev, local-atom, local-name); As type_name is set to one of the predefined device type names in most input drivers. Some drivers set it to local-name which I believe is wrong. Any opinions? I would agree with this analysis. If you look at the protocol and library specifications, they clearly indicate that the strings in XI.h are to be interned as atoms and compared with the type field. The protocol spec has some unclear verbiage about the name that was probably missinterpreted by the person who wrote the man page. The library spec doesn't define the 'name' at all. Unfortunately, the type names defined in XI.h aren't really useful because they don't contain the values you need ... for Wacom tablets, for example, you want to be able to distinguish the tip and eraser ends of the stylus. (They appear as different devices in XFree86.) It's not clear to me whether passing some other atom in the type field is legal without a protocol spec revision. Currently GTK+ determines the type of the device by string comparison of the name field and hopes people gives devices conventional names. If the type enumeration was extended, we could switch to that, but in any case, as long as the name field is left as it currently, changing the -type field won't hurt GTK+. Regards Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XJANITOR] : bug fix in savage driver
On Wed, 2003-06-04 at 14:59, [EMAIL PROTECTED] wrote:
Of course, there are such advantages to using bugzilla, but the above listed
steps are a lot more overhead for submission of trivial patches than
cvs diff foo.c | mail -s Trivial patch to foo [EMAIL PROTECTED]
For a very short patch like this:
Isn't the number of patches where you don't want:
- An explanation of what is wrong
- A bug number to be ability to refer to the change later
- The ability to add further comments to the bug report
if more information is needed
Really tiny? At least for GTK+, a good fraction
of the trivial patches that don't need further explanation
people send in tend to be of the form:
- /* use widget */
+ if (widget)
+ /* use widget */
[...]
diff -u -r1.13 xf86MiscExt.c
--- xf86MiscExt.c 3 Apr 2003 16:15:56 - 1.13
+++ xf86MiscExt.c 4 Jun 2003 18:44:04 -
@@ -618,7 +618,7 @@
{
ScrnInfoPtr pScr = xf86Screens[scrnIndex];
-DEBUG_P(MiscExtGetFilePaths);
+DEBUG_P(MiscExtPassMessage);
if (*pScr-HandleMessage == NULL)
return BadImplementation;
a simpler submission method seems more appropriate.
Anyone know anything more about the mythical email interface to bugzilla?
We have some patches in the bugzilla.gnome.org to allow it, but:
- Patching bugzilla extensively degrades your ability
to upgrade to newer versions, so take the advice of experience,
try to avoid it.
- Bugzilla really doesn't want to send mail to people without
accounts; so, if you get a bug submitted by a non-account-holder
it's sort of second class
Something more sophisticated (email creation of accounts, etc)
is certainly theortically possible, but I don't know of an
implementation.
Regards,
Owen
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XRENDER extension docs?
On Thu, 2003-02-27 at 14:42, Keith Packard wrote: Granted, if you have hardware alpha blits that will be the fastest way to do this. But if you don't have hardware alpha blits (and lots of cards supported by XFree86 do not), you can still speed up anti-aliased text quite a lot by using a 4 or 8 level scheme using multiple mono bitmaps. I suppose, but it wouldn't be compatible with the Render semantics. If I'd heard users complaining about text performance, I'd be more interested. Plus, the number of users with cards that can't support image compositing is rapidly declining; essentially any card that has even the smallest amount of acceleration for 3D graphics can accelerate Render. Actually, we get a fair number of complaints about AA-gnome-terminal speed, though some of that is just bugs in gnome-terminal that have now been fixed. But the software side could be made many times faster; especially considering that gnome-terminal is almost always text-on-constant background. And text-on-constant background should possible to make as fast as PCI/AGP write bandwidth. (*) (A lot slower than hardware compositing, but not remotely slow.) Regards, Owen (*) There are two levels of server-side optimization you can do for text-on-constant-background. a) If you keep track of the fact that a Pixmap is constant color, you can migrate from video ram to system ram about 100x faster than actually copying the data. Compositing system-ram-to-system-ram is fast. b) If you keep track of the fact that a Pixmap is constant color, you could have special-cased compositing routines that avoid even having to read the destination image. But this involves yet more paths in the compositing code. (Yuck.) This one is also harder to properly handle for the multiple-write case. You'd probably have to keep track of a constant-color _region_. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: what is a proximityevent
On Sat, 2003-02-22 at 04:22, Thomas Zander wrote: As I am still trying to code a driver I am just guessing which Xfree technologies might work for me, since I can't find any list or api docs site.. Can someone please tell me what a xf86PostProximityEvent() would do? I found it in the penmount driver. I am wondering if it might help me with buggy hardware (touchscreen) that sends me a combination of mouse-release and mouse-down events (directly after one another) when the did not really occur. Secondly I got pointer to using 'xf86usleep()' but I'm not clear on the task structure of an input driver. I'd like to have an extra thread to do a timer like action, but I'm not sure how to do that (can I just fork?) Any ideas or pointers are greatly appriciated Proximity events report to applications when the user lifts a drawing tablet pen up or puts it back down. If a touchscreen allowed the user to move the cursor without clicking they might be relevant there too, but it's mostly a graphics tablet thing. I can't help you with the rest of your question Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: xterm and UTF8
On Fri, 2003-02-21 at 12:47, Kean Johnston wrote: There's a libcharset that I think comes with libiconv and is also used in GLib that you can use to work around this problem. Which is fine if you use GNU iconv. For those of us that use the iconv as it was originally invented, libcharset doesn't seem to help very much. Maybe I am missing what its trying to do but certainly on Unixware and OpenServer, it does nothing of any use. The way I got around this on OpenServer was (I think) rather sneaky. Our iconv() lets you add in a .so for any given encoding. So I added the ability to define in the iconv data file a fallback mechanism ... basically * * for the from to fields. Then I simply put the whole of GNU iconv in under that entry. So our system defined conversions are used first, and for all those Linux-centric applications that are so badly written to really only support one OS now just work. Note that iconv as originally invented is ENTIRELY BROKEN because no list of standardized encoding names was specified and no set of encodings was required. I don't know what politics or technical oversight was behind this, but it means that using iconv() portably is impossible without extra infrastructure. The GLib library (used by GTK+, GNOME, etc) works around this by using the libcharset data in both directions ... as well as getting a standardized form of encodings reported by the operating system, it will use it convert standardized names into names that are likely to work for iconv() on a particular system. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XCursor: left_ptr_watch does not change with theme
On Tue, 2003-02-04 at 00:04, Brandon Wright wrote: With my attempts at theming Xcursor I have run into a deadlock. No matter what themes I use or create, none of them correctly change left_ptr_watch. Instead, the theme will default onto the left_ptr_watch from whiteglass. I did notice that in xc/lib/Xcursor/library.c that left_ptr_watch seems to be missing from the array that contains the other defined cursors. left_ptr_watch isn't a standard X cursor. Instead, the way it works is that when Xlib gets a request to create a bitmap cursor, libXcursor creates a hash value from the bits, and sees if there is a cursor with that hash value as a name. This hack allows libXcursor to theme custom bitmap cursors from programs like Mozilla. So, your theme needs a symlink: [big long string of hex digts] = left_ptr_watch see the existing themes for how the right name. Regards, Owen [ There is an environment variable you can set to trace what the cursors and hash values are that a program is creating, if you want to figure it out the name for other bitmap cursors. Search for getenv in the Xcursor sources ] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: If you were writing a Windows and X clipboard integration manager...
Harold L Hunt II [EMAIL PROTECTED] writes: ...how would you do it, in 150 words or less? Seriously, I have been working on this for over a year and I would love to hear some of the ideas that people have because I am completely stumped on how to make such a clipboard manager work properly. You really want a server extension (or you could do it in the server, but that would prevent you from using existing client code to retrieve the clipboard contents ... a non-trivial task.) See discussion from: https://listman.redhat.com/pipermail/xdg-list/2002-November/000881.html The extension discussed there will *not* be part of XFree86-4.3, but is the right way of doing it and likely will make it in at some future point. It would be nice if someone responded this time... [ Hint, demanding a response is a really good way to discourage people from responding ] Regard,s Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: If you were writing a Windows and X clipboard integration manager...
Harold L Hunt II [EMAIL PROTECTED] writes: Owen, Owen Taylor wrote: Harold L Hunt II [EMAIL PROTECTED] writes: ...how would you do it, in 150 words or less? Seriously, I have been working on this for over a year and I would love to hear some of the ideas that people have because I am completely stumped on how to make such a clipboard manager work properly. You really want a server extension (or you could do it in the server, but that would prevent you from using existing client code to retrieve the clipboard contents ... a non-trivial task.) Ah ha! Now there is a new idea that I had not thought of yet. This could be promising. Are you saying that I could write a server extension that only Cygwin/XFree86 uses and that such an extension would give me access to the internals that I need? Or, are you saying that there needs to be a new generic server extension that all clients need to support in order for us to play nicely with them? There is no need for clients to use the extension, just the clipboard manager program. The thread on xdg-list has the details. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
