RE: RELNOTES for 4.3.0
RandR integration with partial enable of features? -Original Message- From: Alan Hourihane [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 19, 2003 12:15 To: [EMAIL PROTECTED] Subject: RELNOTES for 4.3.0 Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Mesa 4.0.4 is included for OpenGL(tm) support. * AMD x86-64 support. * Support for OpenBSD/sparc64. * Major OS/2 support updates. * 2D Acceleration for the Trident CyberBladeXP/Ai1 chipsets * Intel 845G support for Xvideo, 2D and 3D. * nVidia GeForce 4 support * ATI Radeon 9x00 support for 2D and 3D excluding the 9500 and 9700 for 3D acceleration. (Need comments about M7,M9 support ) * Major SiS driver updates for some of the latest chipsets. Unfortunately the SiS 3D driver has had to be disabled. No one took up the challenge to port the driver to Mesa 4.x. * National Semiconductor SC1x00, GX1 and GX2 chipset support. * Indirect GLX acceleration for the MacOS X Xserver. * Rootless Xserver for Cygwin/XFree86 (experimental) * An Xcursor library for alpha blended and animated cursors. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
I'm wondering why my fonts have become so very beutiful since 4.2... :) On Wed, Feb 19, 2003 at 11:14:55AM +, Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Mesa 4.0.4 is included for OpenGL(tm) support. * AMD x86-64 support. * Support for OpenBSD/sparc64. * Major OS/2 support updates. * 2D Acceleration for the Trident CyberBladeXP/Ai1 chipsets * Intel 845G support for Xvideo, 2D and 3D. * nVidia GeForce 4 support * ATI Radeon 9x00 support for 2D and 3D excluding the 9500 and 9700 for 3D acceleration. (Need comments about M7,M9 support ) * Major SiS driver updates for some of the latest chipsets. Unfortunately the SiS 3D driver has had to be disabled. No one took up the challenge to port the driver to Mesa 4.x. * National Semiconductor SC1x00, GX1 and GX2 chipset support. * Indirect GLX acceleration for the MacOS X Xserver. * Rootless Xserver for Cygwin/XFree86 (experimental) * An Xcursor library for alpha blended and animated cursors. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Thomas Zander ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
In [EMAIL PROTECTED], on 02/19/03 at 11:14 AM, Alan Hourihane [EMAIL PROTECTED] said: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Major OS/2 support updates. ??? Where do they come from? Frank. -- Frank Giessler Klinikum der Universitaet Jena Tel.: +49-3641-9 35259 Biomagnetisches Zentrum Fax : +49-3641-9 35355 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Wed, Feb 19, 2003 at 12:37:45 +0100, Frank Giessler wrote: In [EMAIL PROTECTED], on 02/19/03 at 11:14 AM, Alan Hourihane [EMAIL PROTECTED] said: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Major OS/2 support updates. ??? Where do they come from? Holger Veit. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Mit, 2003-02-19 at 10:02, Alan Hourihane wrote: On Wed, Feb 19, 2003 at 01:46:39 +0100, Michel Dänzer wrote: On Die, 2003-02-18 at 20:10, Alan Hourihane wrote: On Tue, Feb 18, 2003 at 10:49:58 -0800, Nolan Leake wrote: On Sun, 2003-02-16 at 16:36, Mark Vojkovich wrote: I don't really know what the point of fbIsVirtual was. Apps that use ShadowFBInit need to repaint when entering the VT. We didn't have the EnableDisableFBAccess stuff when I wrote shadowfb and the refresh at EnterVT was to catch the copy from the old root window backing pixmap. With EnableDisableFBAccess handling exposures, it shouldn't be needed anymore but we definitely don't want to block EnableDisableFBAccess like the code is doing. It seems like having ShadowFBInit call ShadowFBInit2 with FALSE is the correct behavior. Experimentation shows this to remove the corruption. The previous shadowfb code blocked EnableDisableFBAccess and updated on VT switching. Since the code looked stale (I couldn't find where the screen got stored in the backing pixmap anywhere), I disabled it for the vmware driver, but since I didn't have a way to test the other clients of shadowfb, I preserved the old behavior for them. If having ShadowFBInit call ShadowFBInit2 with FALSE works for all clients, then the fbIsVirtual flag can be removed entirely; the only caller of ShadowFBInit2 is vmware.c, and it passes in FALSE. O.k. Thanks Nolan. I've just removed that code from the CVS. You missed this. Thanks, although there's no functional difference. It didn't build anymore... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: FW: [Xpert]2 mice - 2 pointer ?!?
We have a product that can have up to 4 touch screens and has a track-ball controlled pointer. Iften people operate the product in a two-handed manner, and occasionally more than one operator will use the product at a given time. the upshot of this is that ideally there would be a pointer for the trackball that isn't effected by touchscreen presses, and separate invisible pointers for each of the touchscreens. The setup is currently impossible in Xfree86. I'm beginning to understand what you want here. I don't think you really need pointers for the touch-screens; just events when they are pressed. I haven't checked, but I think that one of the standard extensions (perhaps XInputExtension) should be able to do that for you. At some level this isn't really a mouse click; if you want standard apps to behave as if they received a mouse-click, then you want a wrapper app to convert touch-screen presses into synthetic events sent to the standard app (perhaps indirectly via the window manager). Thats a pretty good idea, i'll have a delve into that for my current application. I'd say, however that this functionality is something almost all multiple touchscreen users will want, so that doesnt help everyone. Another concrete example is when implementing a collaborative decktop in whcih you want a separate pointer for each of the users remotely viewing that desktop. Are you going to let them type into different windows at the same time ? That really would be two pointers. However I think that should be done by the collaboration software, not by X. How could the collaborations software do this if X cant support multiple main focuses? I presume you would have an app that is in charge of reading the 'remote events' and draws two virtual mouse pointers and sythetically delivers the events? I'm not convinced that two pointers are a good idea on a collaborative desktop, forcing the participants to share a pointer helps them to share their focus. Without it they could easily each do their own thing and stop watching what the other one is doing: a good way to reduce the efficiency of the collaboration ? Its something people want to do... *shug* not my area, but i've seen several discussions about it. And don't forget that most current graphics cards only have one hardware cursor. XFree86 still has framework for soft cursors, no? Anyhow, thanks for the solution! Its a shame that X isn't going to be able to cope with multiple focus trees, but I agree the issues are many, and the need little... Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Mit, 2003-02-19 at 12:14, Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. [...] * ATI Radeon 9x00 support for 2D and 3D excluding the 9500 and 9700 for 3D acceleration. It might be worth mentioning the new features of the Radeon 3D drivers (hardware TCL, ...)? (Need comments about M7,M9 support ) Both fully supported AFAICT. The vertical blank ioctl in the DRM might also be worth pointing out? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Wed, Feb 19, 2003 at 01:28:12PM +0100, Holger Veit wrote: On Wed, Feb 19, 2003 at 11:49:07AM +, Alan Hourihane wrote: On Wed, Feb 19, 2003 at 12:37:45 +0100, Frank Giessler wrote: In [EMAIL PROTECTED], on 02/19/03 at 11:14 AM, Alan Hourihane [EMAIL PROTECTED] said: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Major OS/2 support updates. ??? Where do they come from? Holger Veit. To be precise, considerable work has been done for this release by Frank Giessler. Honour to those who really deserve it. I'm puzzled why it was Frank who asked the question then... Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
In [EMAIL PROTECTED], on 02/19/03 at 01:05 PM, Alan Hourihane [EMAIL PROTECTED] said: To be precise, considerable work has been done for this release by Frank Giessler. Honour to those who really deserve it. I'm puzzled why it was Frank who asked the question then... Sorry for the confusion, I didn't realize that the mentioned updates were already one year old. That was before my activity. Frank. -- Frank Giessler Klinikum der Universitaet Jena Tel.: +49-3641-9 35259 Biomagnetisches Zentrum Fax : +49-3641-9 35355 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[PATCH] Make Radeon and R128 DRI detect processor pagesize at runtime
Here is the original patch comment, with my own comments below. Please apply patch to 4.2.99.x, with plans of a better long term solution for the future planned for later. === Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html === This probably should be rewritten to be outside of the drivers themselves so that it doesn't have to be done per-driver. I'm applying this to our XFree86 for now however until I've got time to investigate doing it more generically. Architectures like Itanium, and Alpha, and probably many others as well do not use 4Kb page size, at least not by default, and they may have a different page size from one machine to the next, or from one OS kernel build to the next. Linux allows the page size to be configured at build time for processors that support it, however the current XFree86 source either hard codes a fixed page size, such as the case for Alpha, or uses a default of 4K which breaks on other architectures. Some Alpha machines use 8Kb for example. The proper long term fix for this IMHO is to make either a DRI global variable, or an X server global variable to store the architecture's pagesize and pagemask at server startup, and let drivers and modules use this information as needed. I think the best place is probably in xf86Globals.c, but I want to investigate it more first. The server should call an OS function to get the page size once only, and then everywhere that needs to know it should use the global. There are 2 choices at least for this that I am aware of, and they are: 1) getpagesize() 2) setconf(_SC_PAGESIZE) getpagesize() is considered legacy in POSIX, and not guaranteed to be on all systems. HPUX does not have it for example. setconf(_SC_PAGESIZE) is defined by SuSv3 at least, and perhaps SuSv2 although I'd have to confirm that. In order to maximize portability, it would be best to determine if the OS has setconf() and use it, and if not, to fall back to getpagesize() instead, and if that isn't supported, to perhaps allow 2 Imake defines to set the pagesize at buildtime. The only problem I can see with this, is the case where 2 operating systems both on the same architecture, where one supports setconf() lets say and the other does not. If we hard code setconf on the OS building the X server, it is theoretically possible that it wont run on other OS's and thus break the binary compatibility across architectures idea. Thinking about that some more, I decided that if the call is done in the X server itself, it should not be a problem really because it is the drivers that are cross OS in one arch, not the server itself. Also, to maximize portability anally, one could do a run time test of return of getconf() and if not supported, fall back to setconf() and then to hard coded compile time defaults. Any comments about any of this? -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat Patch by Chris Ahna: Fixes critical page size problems on ia64 architecture. See following URL for details: https://external-lists.valinux.com/archives/linux-ia64/2001-August/002037.html Comment by [EMAIL PROTECTED]: This probably should be rewritten to be outside of the drivers themselves so that it doesn't have to be done per-driver. I'm applying this to our XFree86 for now however until I've got time to investigate doing it more generically. diff -ur xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c --- xc/programs/Xserver/hw/xfree86/drivers/ati.ORIG/r128_dri.c 2002-10-20 02:48:27.0 +0900 +++ xc/programs/Xserver/hw/xfree86/drivers/ati/r128_dri.c 2002-10-20 +03:05:24.0 +0900 @@ -54,15 +54,7 @@ #include GL/glxtokens.h #include sarea.h -/* ?? HACK - for now, put this here... */ -/* ?? Alpha - this may need to be a variable to handle UP1x00 vs TITAN */ -#if defined(__alpha__) -# define DRM_PAGE_SIZE 8192 -#elif defined(__ia64__) -# define DRM_PAGE_SIZE getpagesize() -#else -# define DRM_PAGE_SIZE 4096 -#endif +static size_t r128_drm_page_size; /* Initialize the visual configs that are supported by the hardware. These are combined with the visual configs that the indirect @@ -489,11 +481,11 @@ /* Initialize the CCE ring buffer data */ info-ringStart = info-agpOffset; -info-ringMapSize = info-ringSize*1024*1024 + DRM_PAGE_SIZE; +info-ringMapSize = info-ringSize*1024*1024 + r128_drm_page_size; info-ringSizeLog2QW = R128MinBits(info-ringSize*1024*1024/8) - 1; info-ringReadOffset = info-ringStart +
Software cursors - was RE: FW: [Xpert]2 mice - 2 pointer ?!?
On Wed, 19 Feb 2003, Rob Taylor wrote: XFree86 still has framework for soft cursors, no? The framework yes, but drivers seem to have problems with DRI and XV and software cursurs, and seem to be trying to disable software cursors. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
At 11:14 AM + 2/19/03, Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Indirect GLX acceleration for the MacOS X Xserver. Some other Mac OS X Xserver improvements (summarize as you see fit): - Smaller memory footprint and faster 2-D drawing in rootless mode - Full screen mode uses shadowfb for much faster 2-D drawing At 6:12 PM +0100 2/19/03, Juliusz Chroboczek wrote: Partial rewrite of the ``freetype'' backend. The new version is based on FreeType 2, and handles TrueType (including OpenType/TTF), OpenType/CFF and Type 1 fonts. The old ``type1'' font backend is deprecated, and only used for CIDFonts by default. And - Ability to use native fonts on Mac OS X --Torrey ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Wed, 19 Feb 2003, Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Mesa 4.0.4 is included for OpenGL(tm) support. * AMD x86-64 support. * Support for OpenBSD/sparc64. * Major OS/2 support updates. * 2D Acceleration for the Trident CyberBladeXP/Ai1 chipsets * Intel 845G support for Xvideo, 2D and 3D. * nVidia GeForce 4 support NVIDIA nForce2 integrated graphics, GeForce4, GeForce FX support. * ATI Radeon 9x00 support for 2D and 3D excluding the 9500 and 9700 for 3D acceleration. (Need comments about M7,M9 support ) * Major SiS driver updates for some of the latest chipsets. Unfortunately the SiS 3D driver has had to be disabled. No one took up the challenge to port the driver to Mesa 4.x. * National Semiconductor SC1x00, GX1 and GX2 chipset support. * Indirect GLX acceleration for the MacOS X Xserver. * Rootless Xserver for Cygwin/XFree86 (experimental) * An Xcursor library for alpha blended and animated cursors. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
On Wed, 19 Feb 2003, Keith Packard wrote: Yes, they are rather system specific, but FreeType2 uses setjmp and longjmp extensively for error recovery. Disallowing setjmp and longjmp would make using FreeType2 rather difficult. I believe the approach taken will at least work in the majority of cases, as long as setjmp/longjmp are exported as regular functions and jmp_buf is no larger than xf86jmp_buf. Because the system setjmp.h is included when referencing those functions, it may be wise to place a check there to ensure xf86jmp_buf is large enough; that would catch systems for which this technique will fail. What are the risks of pulling in other system specific stuff that shouldn't be included? It seems like the wrapped versions could be extended so that they would work correctly. Either let the jmpbuf get passed into them, or have a single global jmpbuf that is used to avoid the stack disapearing problem. It would make the xf86 version more limited than the system version, but unless FreeType2 is nesting setjmp calls it should work. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xterm and UTF8
On Wed, Feb 19, 2003 at 08:53:14PM +0100, Thomas Zander wrote: I've heard the same discussion on KDE lists. And as on KDE the point is that the whole system has to be utf-8 to work correctly. Close -- the way Red Hat 8 is set up, it seems like the whole world needs to be UTF8 :/ This is an exaggeration, but it's wider than just the single system. As I mentioned, ssh'ing into a Red Hat box from another non-RHL8 box shows these encoding annoyances. Its news to me that a locale can specify that its utf-8, since I always thought that locales don't define encodings. It's news, then :) You can specify en_US.UTF-8 as your locale. Which implies to me that xterm can recognize, from its environment, the encoding, and act accordingly. Jeff ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
Around 15 o'clock on Feb 19, Kurt J. Lidl wrote: You ought to make the xf86jmp_buf larger than 200 bytes. I have access to a machine where the jmp_buf storage takes 232 bytes already! I made it 400 bytes -- Linux x86 uses 156 bytes, and 256 seemed likely to be problematic on some machines. It's only a matter of stack space in some very limited situations, so making it way too big won't have significant consequences. The main thing is to make sure it's big enough by checking xf86jmp_buf against jmp_buf when building the base server. -ketih ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
Around 15 o'clock on Feb 19, Stuart Anderson wrote: It seems like the wrapped versions could be extended so that they would work correctly. That's not possible. The fundemental problem is that setjmp captures the execution context (more or less the continuation) from its caller, including the stack pointer, frame pointer, register contents and program counter. When longjmp is executed, all of that context is reloaded into the CPU and the program resumes execution precisely where setjmp would have returned. As the setjmp man page says: The stack context will be invalidated if the function which called setjmp() returns. So, it's not possible to wrap this function in another function -- the wrapping function will return and invalidate the stack context preserved in the jmp_buf. When longjmp happens, the process attempts to return back inside the setjmp wrapper function except the stack context from that function has been trashed by other use of the stack after it returned the first time. Besides, I don't see how wrapping these functions can solve the portability issues -- there's no data abstraction presented, only a function abstraction. The portability issue is over the size of the jmp_buf datatype, something which is clearly dependent on the libc in use during execution. Referencing the functions through another name will avoid collisions with the local C library and provide precisely the same portability as a wrapper would. One could argue the same should be done with many other transparent libc wrapper functions without loss of portability and could reduce the overhead when calling such functions. One fix that would match the portability assumptions in the current loader would be to write XFree86-specific versions of setjmp and longjmp in assembly for each architecture. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: RELNOTES for 4.3.0
Gatos is focussing on video and TV playback, TV/video-in functionality and video capture. But they are _not_ focussed on 3D to my understanding. thanks for the link to the AIW Radeon 9700 comments. the text outlines that even gatos has not timeframe how their development will proceed. for my understanding its partly related to the limited personal time they do have for dealing with that device. (okay maybe its meant different, but thats how i read that.) -Alex. Gatos have acording to http://gatos.sourceforge.net/supported_cards.php recived document ans sample hardware from ATI. an Romanick wrote: Mark Cuss wrote: A quick question regarding the 9500 and 9700 series Radeons - is support for 3D acceleration planned? Eventually, someday, if ATI releases the relavent documentation and enough developers have the time to do the work. In the meantime, if you're on x86 Linux (or perhaps some BSD flavors that can use Linux binaries), ATI has a very nice binary-only driver. The problem right now is that, even if ATI released all of the documentation available for the chip, there's not enough people with enough time and the right skill sets to bring-up a 3D driver for a new chip. :( ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
Keith Packard wrote (in a message from Wednesday 19) Around 15 o'clock on Feb 19, Stuart Anderson wrote: This approach strikes me as being inherently non-portable wrt the module ABI. setjmp/longjmp are too system specific to be used in modules. Yes, they are rather system specific, but FreeType2 uses setjmp and longjmp extensively for error recovery. Disallowing setjmp and longjmp would make using FreeType2 rather difficult. Given that setjmp/longjmp are not thread safe, wouldn't it be better to have FreeType2 drop them in the future ? For the short term, makeing aliases for xf86setjmp/xf86longjump is probably good enough. Even if the binary compat is broken, the need to run a foreign OS font module is low, since they are open source. The use of xf86setjmp/xf86longjmp should be discouraged. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. I'd suggest the following s3virge driver note: Doublescan modes (320x200) are supported and tested in depth 8 and 16 on DX, but disable XVideo. Doublescan modes on other chipsets are untested. (From patch #5617) -- Kevin ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] DontVtSwitch X server config file option
On Wed, Feb 19, 2003 at 09:58:19AM -0500, Mike A. Harris wrote: This patch by Branden Robinson adds the option DontVTSwitch to the X server serverflags section, which disables VT switching via CTRL-ALT-Fx at runtime. Tested in CVS for a few weeks, and comes from Debian prior to that. Patch has had a fair bit of testing from Debian folk it seems as it's been around for a while. I'm applying it to our builds as well. This is not a bug fix, so I don't expect it to get into 4.3.0, however I thought I would submit it anyway and leave the decision of wether or not to include it up to a CVS commiter, as a lot of people ask about how to disable VTswitching. If it doesn't go in, any comments about it would be appreciated, which I'll communicate back down the line as well. I've just committed this, but it needed some changes to work with the new XKB-configurable hot keys. Did you find that the patch as sent worked in that case? I also found that the operation of xf86EnableVTSwitch() was broken after the XKB hot key changes, and that should be fixed now too. A natural extension of this would be to allow this setting to be changed via the XFree86-Misc extension. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
On Wed, Feb 19, 2003 at 12:20:04PM -0800, Keith Packard wrote: Around 15 o'clock on Feb 19, Stuart Anderson wrote: This approach strikes me as being inherently non-portable wrt the module ABI. setjmp/longjmp are too system specific to be used in modules. Yes, they are rather system specific, but FreeType2 uses setjmp and longjmp extensively for error recovery. Disallowing setjmp and longjmp would make using FreeType2 rather difficult. I believe the approach taken will at least work in the majority of cases, as long as setjmp/longjmp are exported as regular functions and jmp_buf is no larger than xf86jmp_buf. Because the system setjmp.h is included when referencing those functions, it may be wise to place a check there to ensure xf86jmp_buf is large enough; that would catch systems for which this technique will fail. Yes, I think that should work (providing we don't get too much other stuff included as a result of including setjmp.h directly). I'd set the size of xf86jmp_buf to something large. Maybe 4K would be sufficiently large without being excessive? David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xterm and UTF8
On Wed, Feb 19, 2003 at 03:48:02PM -0500, Jeff Garzik wrote: On Wed, Feb 19, 2003 at 08:53:14PM +0100, Thomas Zander wrote: Its news to me that a locale can specify that its utf-8, since I always thought that locales don't define encodings. It's news, then :) You can specify en_US.UTF-8 as your locale. Which implies to me that xterm can recognize, from its environment, the encoding, and act accordingly. Hope you aren't using the locale standard 'Variation' variable for that; in most europe countries that will give problems since they allready use it for the EURO variation. Do you know who came up with this idea? Is there a mailing list I can look at? Knowing my locales; encondings should not be in a locale! (Since the user can override them) Thanx! -- Thomas Zander ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: logging out an X session
On Thu, Feb 20, 2003 at 12:00:43AM -0600, Omon Edeki wrote: I am desperately trying to write a program to log out a user from a linux KDE/GNOME X window session.In trying to do this, I am killing all the users' processes using kill(pid_t pid, SIGKILL) to all the users processes. That's a bad plan by design. You should use SIGKILL only as last resort. Instead you chould start sending SIGHUP to all processes of the user, wait a few seconds, send SIGTERM, wait another few seconds and send SIGKILL finally. An x server (?) is still running somewhere in the background, The best approach is of course just to terminate the X11 server. But you must *not* use SIGKILL which would leave the console in a garbled state. Use SIGTERM instead. Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
