Experimental Snapshot v4.3.99.901 - SIS-DRI-Driver-Problem
Hi, I have tried your latest Snapshot and have a problem using the SIS-DRI-Driver at WineX if it comes to Direct3D games OpenGL games work perfect also DirectDraw... BUT as said Direct3D games lock-up (only mouse works still) before I get shown anything the same is for the videos in the game this all worked perfect with the old SIS-Driver but there I had the problem that in any game if DRI was used - I got a lock-up, even TuxRacers Could you please look into that and tell me if the next release will fix this problem could you also maybe tell me what could have been the problem with the old SIS-Driver? Btw. after installing the new X Snapshot autostarting of X doesnt work anymore it tries but I get back to login mask without X after logging in and using startx this works. Regards, Andreas Allacher
Experimental Snapshot v4.3.99.901 - SIS-DRI-Driver-Problem
Hi, I have tried your latest Snapshot and have a problem using the SIS-DRI-Driver at WineX if it comes to Direct3D games OpenGL games work perfect also DirectDraw... BUT as said Direct3D games lock-up (only mouse works still) before I get shown anything the same is for the videos in the game this all worked perfect with the old SIS-Driver but there I had the problem that in any game if DRI was used - I got a lock-up, even TuxRacers Could you please look into that and tell me if the next release will fix this problem could you also maybe tell me what could have been the problem with the old SIS-Driver? One other thing: with glxinfo I got about 375 FPS with the old driver with the new I get around 200FPS is it still that fast as the old but only glxinfo detects it wrong?. Btw. after installing the new X Snapshot autostarting of X doesnt work anymore it tries but I get back to login mask without X after logging in and using startx this works. Regards, Andreas Allacher ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
GeForce 4 Ti 4200 on Dell Inspiron 8500
Hi, I have just tried to run XFree86 4.3.99.901 on a Dell Inspiron 8500 with a GeForce4 Ti 4200. Globally it works well, except for three things: 1) Although X detects the graphic chip (the log says: (--) Chipset GeForce4 4200 Go found), when I run XFree86 -configure the chip's correct name is not written in XF86Config.new: Driver nv VendorName nVidia Corporation BoardName Unknown Board 2) I could not get the integrated flat panel (1680x1050) working without explicitly adding a specific modeline: Modeline 1680x1050 147.14 1680 1784 1968 2256 1050 1051 1054 1087 However, X correctly detects my flat panel: (--) NV(0): Panel size is 1680 x 1050 (--) NV(0): VideoRAM: 65536 kBytes (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) (II) NV(0): Monitor0: Using default hsync range of 28.00-33.00 kHz (II) NV(0): Monitor0: Using default vrefresh range of 43.00-72.00 Hz (II) NV(0): Clock range: 12.00 to 350.00 MHz But it lacks a default 1680x1050 mode, so it defaults to 640x480. Maybe adding a default 1680x1050 mode would help Dell laptop users who don't want to bother with modelines (or aren't skilled enough) ? 3) When I switch back from graphics mode to text mode, the text display is messed up: the display is not correctly centered, one pixel out of two remains off, and horizontal lines appear when some text is printed on the last line. Here is the lspci output corresponding to my graphics adapter: 01:00.0 Class 0300: 10de:0286 (rev a1) 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 Go AGP 8x] (rev a1) (prog-if 00 [VGA]) Subsystem: Dell Computer Corporation: Unknown device 0179Flags: bus master, VGA palette snoop, 66Mhz, medium devsel, latency 32, IRQ 11Memory at fc00 (32-bit, non-prefetchable) [size=16M]Memory at f000 (32-bit, prefetchable) [size=64M] Expansion ROM at 8000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 3.0 Best regards, congratulations for the great work done so far. Christophe Jacquet. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Dealing with images
Hi all, I posted the following message to the Xouvert list. I know that cross-posting to different lists is not generally a good idea, but I maybe somebody might be interested in this. -- Forwarded Message -- Subject: Dealing with images Date: Sunday 07 December 2003 16:39 From: Gian Filippo Pinzari [EMAIL PROTECTED] To: General discussion about the Xouvert X server [EMAIL PROTECTED] On Sunday 07 December 2003 05:05, Herbert Snorrason wrote: Now the question is: Who won't want it? PNG is in nearly every way *the* lossless raster format. Nearly everyone with X is going to have libpng available. It would, frankly, make sense to promote it to a default format for any and all bitmap graphics. I'm personally advocating addition of PNG and JPEG support to the X protocol since long. Translation of X bitmaps to PNG and JPEG is in already NX. Images are decompressed back to X bitmaps by the X server side proxy. Only 'NX aware' X clients can use it as it's not a standard X extension and you need to run the NX proxy system, so it's clearly not a general solution. In NX we need our own Xlib to make this available to all X clients and this is even more clumsy. When I'm saying that advocating PNG and JPEG addition, I'm not talking about XIE. I'm talking about a way to: - Save bandwidth sending images in a more compact format. - Allow clients to 'stream' images on the link and be notified when the image has been completely recomposed at the X server side. Additional functionalities (all implemented in NX) that could greatly improve network efficiency are: - Separate alpha channel from the PutImage X bitmap so alpha (highly compressible) can be cached/compressed as a separate message. This would allow to add alpha to JPEG or other image formats that don't natively support it. - Store 'colortables' in the X server to be used to decompress the X bitmaps, again as a separate (highly cacheable) protocol message. I'm not talking about the existing X colormaps here, but the mapping of values to pixels of the TrueColor visual, to be used to decompress the image. - Store images at X server side and let clients verify if the image needs to be transferred over the link. X server could store PNG an JPEG images in memory or disk and decompress them on the fly, when needed. This is different in respect of pixmaps. Clients couldn't manipulate the image, just copy (that is uncompress) the image to the drawable. - Support other pluggable image formats, such as MS RDP bitmaps or RFB screen updates in different encodings. Looking even further, I think that X needs to deal with the problem of transferring huge amounts of bitmap data over the network in a smarter and definitive way. I'm sure that many people will say that X clients should simply forget X bitmaps and use SVG or other vector graphics. How these people are going to run a X video-conferencing application or a media player over the network? They don't say. They just wonder why you would ever want to do that. What I propose is to make the PutImage request obsolete (note, only the request, not the idea that clients need bitmaps) and let clients use arbitrary image streaming codecs. The X client should be able to query which codecs are available, create a 'stream' object and add 'frames' to it. The X server should decompress the frames to a virtual frame-buffer and provide a way to CopyArea from the frame buffer to the drawables. Then clients should be able to use all the usual X protocol requests to manipulate the drawable and display their output. I started to talk about this with Leon Shiman of MAS but we didn't have a chance yet to discuss the technical details. Clearly this overlaps in many ways with what MAS is doing. There is a big difference, anyway. MAS is intended to deal with streaming and displaying of real time MM contents while our scope is session persistency, compression and network efficiency. MAS is the solution for MM (but, as I said to Leon, the project needs to leave the lab and go in the wild) but we still need a way to manage images in average X clients (web browsers, office automation applications) that don't have time requirements but can't afford to loose data due to the stateful nature of X protocol. Regards, /Gian Filippo Pinzari. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
It'll take more than advocacy to make it a standard. I don't need to tell you, I'm certain, that in Open Source software the best way to make things happen is to do them. To be a Standard though, you need to write a specification and have it go through X.org's standardization process. A proof of concept, in the form of an implementation, is useful too. X.org is currently in the process of aligning its processes with the open source movement. The legal framework is expected to be in place by the first of the year. Even though that part won't be ready for a few more weeks, X.org has already begun the other part by sponsoring an open development source tree on freedesktop.org. This tree will become the basis for X.org future releases. Commit privileges in the X.org tree are free for the asking -- you do your work on a branch and when the X.org community agree, your work will be merged into the main branch and become part of the next release. The people doing Cygwin-X have already started working in the X.org tree. -- Kaleb S. KEITHLEY Gian Filippo Pinzari wrote: Hi all, I posted the following message to the Xouvert list. I know that cross-posting to different lists is not generally a good idea, but I maybe somebody might be interested in this. -- Forwarded Message -- Subject: Dealing with images Date: Sunday 07 December 2003 16:39 From: Gian Filippo Pinzari [EMAIL PROTECTED] To: General discussion about the Xouvert X server [EMAIL PROTECTED] On Sunday 07 December 2003 05:05, Herbert Snorrason wrote: Now the question is: Who won't want it? PNG is in nearly every way *the* lossless raster format. Nearly everyone with X is going to have libpng available. It would, frankly, make sense to promote it to a default format for any and all bitmap graphics. I'm personally advocating addition of PNG and JPEG support to the X protocol since long. Translation of X bitmaps to PNG and JPEG is in already NX. Images are decompressed back to X bitmaps by the X server side proxy. Only 'NX aware' X clients can use it as it's not a standard X extension and you need to run the NX proxy system, so it's clearly not a general solution. In NX we need our own Xlib to make this available to all X clients and this is even more clumsy. When I'm saying that advocating PNG and JPEG addition, I'm not talking about XIE. I'm talking about a way to: - Save bandwidth sending images in a more compact format. - Allow clients to 'stream' images on the link and be notified when the image has been completely recomposed at the X server side. Additional functionalities (all implemented in NX) that could greatly improve network efficiency are: - Separate alpha channel from the PutImage X bitmap so alpha (highly compressible) can be cached/compressed as a separate message. This would allow to add alpha to JPEG or other image formats that don't natively support it. - Store 'colortables' in the X server to be used to decompress the X bitmaps, again as a separate (highly cacheable) protocol message. I'm not talking about the existing X colormaps here, but the mapping of values to pixels of the TrueColor visual, to be used to decompress the image. - Store images at X server side and let clients verify if the image needs to be transferred over the link. X server could store PNG an JPEG images in memory or disk and decompress them on the fly, when needed. This is different in respect of pixmaps. Clients couldn't manipulate the image, just copy (that is uncompress) the image to the drawable. - Support other pluggable image formats, such as MS RDP bitmaps or RFB screen updates in different encodings. Looking even further, I think that X needs to deal with the problem of transferring huge amounts of bitmap data over the network in a smarter and definitive way. I'm sure that many people will say that X clients should simply forget X bitmaps and use SVG or other vector graphics. How these people are going to run a X video-conferencing application or a media player over the network? They don't say. They just wonder why you would ever want to do that. What I propose is to make the PutImage request obsolete (note, only the request, not the idea that clients need bitmaps) and let clients use arbitrary image streaming codecs. The X client should be able to query which codecs are available, create a 'stream' object and add 'frames' to it. The X server should decompress the frames to a virtual frame-buffer and provide a way to CopyArea from the frame buffer to the drawables. Then clients should be able to use all the usual X protocol requests to manipulate the drawable and display their output. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patch for a crash in x86 emulator
On Sat, Dec 06, 2003 at 07:47:30PM -0500, Sergey Babkin wrote: David Dawes wrote: return not NULL pointer but a valid pointer to some trash value, so that their caller would be able to reference it without crashing before the interpreter has a chance to halt. Yes, that is a problem. The INTR_HALTED flag isn't tested until too late. The potential problem of returning a trash value is that could cause bad things too. Maybe the callers of functions that can return NULL need to check for that, and abort the instruction? Then INTR_HALTED will be noticed before moving on to the next instruction. Maybe a better way would be to check in the callers for INTR_HALTED and return immediately. This should handle nested calls relatively easily, with the same thing done in each function. Otherwise if there are nested calls the inner funtions will need to devise some special values to indicate the abort to their callers too. That's a good point. It would handle it nice and consistently. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Configuration file
On Sat, Dec 06, 2003 at 08:17:35PM -0600, [EMAIL PROTECTED] wrote: Hello fellow developers, I was just wondering if there are any plans in a future release to change the XFree86 configuration to XML? There are plans to change how XFree86 is configured, but they are focused more on providing mechanisms for dynamic/runtime configuration and user preferences to complement the automatic configuration introduced in 4.4 than on any specific file formats. The XFree86 configuration file is handled solely by a parser module. You could write a new version of that module which reads a config file in some XML format that you define. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: GeForce 4 Ti 4200 on Dell Inspiron 8500
On Sun, 7 Dec 2003, Christophe Jacquet wrote: 3) When I switch back from graphics mode to text mode, the text display is messed up: the display is not correctly centered, one pixel out of two remains off, and horizontal lines appear when some text is printed on the last line. Did it used to work? I've never had one of these laptops myself so I've never tested on one. Does hitting the Font key fix it up again? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
On Sun, 07 Dec 2003 12:15:07 -0500, Kaleb S. KEITHLEY [EMAIL PROTECTED] wrote: It'll take more than advocacy to make it a standard. I don't need to tell you, I'm certain, that in Open Source software the best way to make things happen is to do them. To be a Standard though, you need to write a specification and have it go through X.org's standardization process. that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. FBSD was tied to that old war horse, Telephone, and following standards and they lost. Linux followed a standard that a genius created and made it happen. throw out the standards group and just take hold of the standard by being there. the group will follow as they can't think just react. Linux proves it. Linux is god. mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: GeForce 4 Ti 4200 on Dell Inspiron 8500
Mark Vojkovich wrote: Did it used to work? I've never had one of these laptops myself so I've never tested on one. Actually, it is the first time I try to get XFree86 working on this laptop. Does hitting the Font key fix it up again? What do you mean with Font key ? If you think of a key enabling to toggle display expansion, to my knowledge there is no such key on the Inspiron 8500. However, I've found out that Diego Santa Cruz, who also owns an Inspiron 8500, notes [1]: I experienced problems when coming from graphical mode back to text mode in that the screen would be all garbled. I disabled the display expansion in the BIOS and the problem disappeared. Regards, Christophe. [1] http://ltswww.epfl.ch/~dsanta/resources/dell-i8500-linux ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
mark kandianis wrote: that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. Standards are what allow Linux to have had even a chance to be here in the first place. If it wasn't for open standards, the Internet wouldn't exist in it's current form - all we'd have is AOL Compuserve with their proprietary formats, and anyone wanting to compete would have to be constantly reverse engineering to be able to interoperate at all (as you can see in the word processor market, where Microsoft changes its file formats every release, and everyone else wastes a ton of effort reverse engineering in order to be compatible). And even the market leaders of Microsoft and Apple participate in standards groups such as the IETF and W3C. The original post pointed out that the image formats used by NX weren't as useful as they could be, because only NX supported them - the solution to that is to get everyone to agree to include it in a standard - otherwise, it will remain something that you can't use with everyone else's software. Linux followed a standard that a genius created and made it happen. Actually, Linux started out following the POSIX standard that a standards group created to make sure all UNIX-like OS'es were compatible, so that all the existing software like gcc, emacs, X, etc. for those other OS'es could be used on Linux. Without that, Linux would probably have gone the road of BeOS - an interesting concept that never really caught on since it had few useful applications. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
On Sun, 07 Dec 2003 12:15:07 -0500, Kaleb S. KEITHLEY [EMAIL PROTECTED] wrote: It'll take more than advocacy to make it a standard. I don't need to tell you, I'm certain, that in Open Source software the best way to make things happen is to do them. To be a Standard though, you need to write a specification and have it go through X.org's standardization process. A proof of concept, in the form of an implementation, is useful too. X.org is currently in the process of aligning its processes with the open source movement. The legal framework is expected to be in place by the first of the year. Even though that part won't be ready for a few more weeks, X.org has already begun the other part by sponsoring an open development source tree on freedesktop.org. This tree will become the basis for X.org future releases. Commit privileges in the X.org tree are free for the asking -- you do your work on a branch and when the X.org community agree, your work will be merged into the main branch and become part of the next release. The people doing Cygwin-X have already started working in the X.org tree. -- Kaleb S. KEITHLEY so this is basically an advertisement? don't waste my time or bandwidth. i thought you had something to say. mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org [was: with images]
KK It'll take more than advocacy to make it a standard. I don't need to KK tell you, I'm certain, that in Open Source software the best way to KK make things happen is to do them. KK To be a Standard though, you need to write a specification and have it KK go through X.org's standardization process. A proof of concept, in the KK form of an implementation, is useful too. Kaleb, If you can explain what we did wrong with UTF8_STRING, please do. Pro memoria, we have a sample implementation, we have a draft standard, and we spent over a year trying to get X.Org to notice. If, however, you cannot point out what we did wrong, then we can only conclude that freedesktop.org is a better forum for the standardi- sation of X protocol extensions. Regards, Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org [was: with images]
Juliusz Chroboczek wrote: Kaleb, If you can explain what we did wrong with UTF8_STRING, please do. Pro memoria, we have a sample implementation, we have a draft standard, and we spent over a year trying to get X.Org to notice. If, however, you cannot point out what we did wrong, then we can only conclude that freedesktop.org is a better forum for the standardi- sation of X protocol extensions. I wasn't involved with X.org when that happened. It's my understanding that the proposal was made when they were busy trying to wrap up a release. They did what they could, i.e. they added UTF8_STRING to the registry. As I indicated to you previously on xfree86-forum, you should be hearing something before very long -- if you still care. -- Kaleb S. KEITHLEY ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org
If you can explain what we did wrong with UTF8_STRING, please do. KK They did what they could, i.e. they added UTF8_STRING to the KK registry. Oh wow. KK As I indicated to you previously on xfree86-forum, you should be KK hearing something before very long Oh good. So they aren't irrelevant at all. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
On Sun, 07 Dec 2003 14:52:50 -0800, Alan Coopersmith [EMAIL PROTECTED] wrote: mark kandianis wrote: that's shit. I really think that's got the cart in front of the horse. I don't see the market leader(s) doing that, to make something saddled to a standards group is a reminder of why LINUX beat FreeBSD. Standards are what allow Linux to have had even a chance to be here in the first place. this from the company that has brought us solaris. (cheap shot but I like it) and as for pOSIX and linux, linux is not limited by the pOSIX standard, it makes the standard by doing it making it happen. i've seen LINUX move beyond and do things that posix has yet to endorse but does so it can be LINUX aware. making something a standard doesn't mean that anyone willl use it? tech is wrecked with lots of 'standards' that went no where. yeah the internet took off. darpa made it happen. lots of govt money can make anything happen. mark If it wasn't for open standards, the Internet wouldn't exist in it's current form - all we'd have is AOL Compuserve with their proprietary formats, and anyone wanting to compete would have to be constantly reverse engineering to be able to interoperate at all (as you can see in the word processor market, where Microsoft changes its file formats every release, and everyone else wastes a ton of effort reverse engineering in order to be compatible). hey wanna buy a standard cheap? i'll sell in on ebay. goes to highest bidder ;-) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org [was: with images]
On 07 Dec 2003 23:18:47 +0100, Juliusz Chroboczek [EMAIL PROTECTED] wrote: KK It'll take more than advocacy to make it a standard. I don't need to KK tell you, I'm certain, that in Open Source software the best way to KK make things happen is to do them. KK To be a Standard though, you need to write a specification and have it KK go through X.org's standardization process. A proof of concept, in the KK form of an implementation, is useful too. Kaleb, If you can explain what we did wrong with UTF8_STRING, please do. Pro memoria, we have a sample implementation, we have a draft standard, and we spent over a year trying to get X.Org to notice. If, however, you cannot point out what we did wrong, then we can only conclude that freedesktop.org is a better forum for the standardi- sation of X protocol extensions. Regards, Juliusz i don't follow this line of argument. that kaleb guy said x.org was going to freedesktop and you think that's the solution? no que comprende. mark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Configuration file
On Sun, Dec 07, 2003 at 02:57:04PM -0500, David Dawes wrote: On Sat, Dec 06, 2003 at 08:17:35PM -0600, [EMAIL PROTECTED] wrote: Hello fellow developers, I was just wondering if there are any plans in a future release to change the XFree86 configuration to XML? There are plans to change how XFree86 is configured, but they are focused more on providing mechanisms for dynamic/runtime configuration and user preferences to complement the automatic configuration introduced in 4.4 than on any specific file formats. Ok, sounds good. The XFree86 configuration file is handled solely by a parser module. You could write a new version of that module which reads a config file in some XML format that you define. Thats great, I am not up to date on the module capabilities in X4, sorry to bother the list with such an obvious question. :) I'm surprised none of the linux distributions out there have exploited this capability for better integration into the rest of the system. Thanks, Vito Caputo ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org [was: with images]
MK i don't follow this line of argument. that kaleb guy said x.org was MK going to MK freedesktop and you think that's the solution? no que comprende. I understand it can be a little bit confusing if you don't have the background. All that follows is my private perception, and doesn't represent an official XFree86 opinion. Kaleb is a respected X11 wizard. While I do not know who is or used to be his employer, for as long as I can remember he has appeared to be close the the ``official'' guardians of the X11 standard -- used to be The Open Group, is X.Org right now. (I don't know whether this was already the case in the MIT X Consortium days.) Our relations with TOG were more or less non-existent, especially after the X11R6.4 licensing debacle; Kaleb was, I believe, the one person close to TOG we would sometimes have a chat with. When TOG gave up the X11 stewardship and X.Org was created, we were hoping to establish a more healthy relationship with them. This hope was abandoned when we actually tried to get them to standardise something we had done -- we were ignored for a year, and then flamed to death for distributing the very extension that had been ignored. (You will find the flamewar archives if you google for ``UTF8_STRING precipitously''.) Kaleb, I hope I didn't mis-represent anything. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Configuration file
On Sun, Dec 07, 2003 at 06:29:24PM -0600, [EMAIL PROTECTED] wrote: On Sun, Dec 07, 2003 at 02:57:04PM -0500, David Dawes wrote: On Sat, Dec 06, 2003 at 08:17:35PM -0600, [EMAIL PROTECTED] wrote: Hello fellow developers, I was just wondering if there are any plans in a future release to change the XFree86 configuration to XML? There are plans to change how XFree86 is configured, but they are focused more on providing mechanisms for dynamic/runtime configuration and user preferences to complement the automatic configuration introduced in 4.4 than on any specific file formats. Ok, sounds good. The XFree86 configuration file is handled solely by a parser module. You could write a new version of that module which reads a config file in some XML format that you define. Thats great, I am not up to date on the module capabilities in X4, sorry My use of the word module might be a little misleading. The parser is statically linked into the XFree86 server executable, but it is in a self-contained library. to bother the list with such an obvious question. :) I'm surprised none of the linux distributions out there have exploited this capability for better integration into the rest of the system. A lot of the things they (don't) do surprise me :-) David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
mark kandianis wrote: and as for pOSIX and linux, linux is not limited by the pOSIX standard, it makes the standard by doing it making it happen. i've seen LINUX move beyond and do things that posix has yet to endorse but does so it can be LINUX aware. All interesting OS'es have extensions beyond the core POSIX standards, but those are often sources of great problems when trying to make portable software such as XFree86. The original question asked about getting it into the standard presumably to avoid such problems. XFree86 already has a number of extensions beyond the core standards - it would be easy to create another one there, but then there's no guarantee of interoperability with other OS'es, and different OS'es end up with different versions, or none at all - a situation you can see today with XFree86 non-standard extensions such as Render or RandR. If all you care about is OS'es which run XFree86, that's not a problem - but that may not even be all Linux distributions in the future if any of them decide to start shipping the Xouvert or freedesktop.org or some other X server instead. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with X.Org
Juliusz Chroboczek wrote: KK As I indicated to you previously on xfree86-forum, you should be KK hearing something before very long Oh good. So they aren't irrelevant at all. I wouldn't say irrelevant - they are still the official keeper of the standards recognized by many companies and organizations, including the LSB UNIX standards. I would allow that their standards process has been very inefficient and unworkable to anyone not actively represented on whichever task force is working on the standard. I believe Mark Vojkovich was actively involed in the Xinerama standardization, but that has been stalled in the final stages for a long time. We got IPv6 support done because Sun and several other members committed to making it happen (and even there we've gone much slower than we hoped for). Unfortunately, while David Dawes represents XFree86 on the Executive Board, I don't know of any active XFree86 developers on the Architecture Task Force, which discusses updates to the core standard itself. (At least on the conference calls, I hear people from HP, IBM, SGI, Sun, and TOG, but don't remember ever hearing anyone not from one of the members.) That's where we've been discussing the IPv6 changes and where I presume the UTF8_STRING changes would be discussed. (There is theoretically an i18n task force, but I don't think it's active since no one's given them anything to talk about.) While it's not widely advertised, anyone can join one of the X Task Forces and participate - unfortunately, the web page on the X.org site about this is currently a cruel joke since it simply tells you to contact the task force chair to join, but gives absolutely no clue how to find out how to contact them (with two exceptions, one of which points to someone who hasn't been the Xinerama task force chair for about a year now). Of course, most of this is on the verge of becoming irrelevant, because even X.org realizes how ineffective it had become and is reorganizing. Some of this came out of the early discussion on the forum list and talks that have gone on since then to reform X.org to actively encourage participation from anyone who is interested. As Kaleb noted, they are pushing hard to get this done ASAP. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc.- Sun Software Group User Experience Engineering: G11N: X Window System ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Dealing with images
Hi Kaleb, On Sunday 07 December 2003 18:15, Kaleb S. KEITHLEY wrote: To be a Standard though, you need to write a specification and have it go through X.org's standardization process. A proof of concept, in the form of an implementation, is useful too. We have the proof of concept. Should we write such a X image compression and streaming specification and submit it for approval to the X consortium? Such an extension would be useless without clients leveraging it. I'm speaking about GNOME, KDE, Mozilla, OpenOffice, Evolution and I could name many more. We need the support of the X developers otherwise it's better to use our time and resources to write a layer that don't need X apps to be aware of it. We already have hard time making a living out of writing OSS software, so I don't think we'll follow the Rule and spend development time and resources in something that, maybe, nobody will ever use. Does OSS development always follow the Rules? Fortunately not. Look at the XDamage extension. There were some talks and a sample implementation from Havoc. It solved a very real problem, so everybody agreed on it. Keith Packard wrote the specification, a better version of the code and it immediately went into the freedesktop X server. As often happens in the OSS world, somebody comes with a solution, then the OSS world elaborates it, improves it, plugs the holes and makes it a standard. We would like to follow the same OSS rule. Unfortunately we are still at the stage that most X people seem to completely ignore (or consider not worth of mention) the work we have done and the problems we are trying to solve. Obviously I think they are wrong, otherwise I would have already stopped complaining in mailing lists ;-). I'm just starting to believe that also the OSS world suffers of the 'not invented here' syndrome. I carefully read the Open Source Desktop Technology Road Map of Jim Gettys: http://freedesktop.org/~jg/roadmap.html It doesn't make any mention of NX. This is really sad. I'm sure Jim knows about our software, so I must argue that he thinks that X doesn't need specific X protocol compression, X image encoding and streaming, a X agent system resolving round-trips at application server side, embedding of different remote desktop protocols in X, a proxy system implementing bandwidth control, encryption, transport over a RTP network, session initiation through SIP and other things we instead need in NX. Should we write a specification for each functionality and wait the X developers to embrace them? It would be fantastic, but I don't think we have the money to live long enough to see this happen. I read in the previous document that Jim Gettys thinks that ssh -X -C or VNC are good enough for most remote computing needs. Well, I think that the proof of the pudding is in eating. I would really like to know if Jim Gettys has ever tried our software and if he had a chance to run it, side by side, with ssh -X -C or VNC. Many X people seem to forget that there is a company whose name is Citrix and another company whose name is Microsoft that have nearly the 100% of the remote computing market. Probably these X people should rather argue that ssh -X -C is no-good. Some weeks ago we received an e-mail from a company that qualified itself as a Citrix partner since 10 years. They told us that they had tried NX and were stunned by the performances. It was the first time, since 10 years, that they had something that could beat Citrix. They are now in the process of becoming distributors. And, yes, they had tried ssh -X -C and VNC. I read again the thread about NX in the old XFree86 forum. The point of Keith Packard and Jim Gettys was that the work that is taking place at freedesktop.org should make possible to run remote X applications with the same efficiency and with the same features provided by NX without any of the NX solutions to the problem. I studied the papers but I don't see any solution to the X image encoding and streaming problem, so I think this is a good place to start working together. And I hope, Kaleb, that your suggestion is not to do all the work by ourselves ;-). Kind regards, /Gian Filippo Pinzari. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC1
On Thu, Dec 04, 2003 at 08:19:59PM -0500, David Dawes wrote: If you have any open bugs in our bugzilla, you need to verify whether or not they are still valid against this release candidate. Send a note here for bugs that are confirmed to still be a problem, and close ones that you confirm are fixed. Bugs that are not confirmed against a release candidate will be closed as a matter of course when 4.4 is released. I haven't seen much reponse here yet regarding new bugs or existing open bugs in bugzilla. Does that mean that most of them are no longer relevant and can be closed? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Fwd: [Bug 931] New: RFE: Update xc/extras/freetype2/ to Freetype 2.1.7...]
David Dawes wrote: Do you mean xc/lib/font/Type1/ vs xc/lib/font/FreeType/ ? In my opinion the xc/lib/font/Type1/ should be retired since it causes server crashes such as Fatal server error: Beziers this big not yet supported and seems to have huge problems with rasterisation at higher resolutions. At Yeah, FatalError() from a font backend is bad. It ought to print a warning and return a relevant error code rather than killing the whole server. Unfortunately it isn't easy to handle that kind of error in a simple way... you can use setjmp/longjmp() for that case but that doesn't do any cleanup nor will it reset the Type1 engine... Yeah, it wouldn't be simple. Disabling the Type1 engine completely when one of these errors happens would even be preferable to aborting the whole X server. What about removing the CID support from the default setup ? [snip] What about handling *.pfa/*.pfb via the FreeType backend and let CID fonts be handled via the old Type1 backend ? That is the current default behaviour. Thanks for the hint (which helped narrowing down the issue... I thought I removed all CID fonts from my Linux machine but somehow I found another bunch... after removing the fonts the Xfree86 server is rock-solid again... :) Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, CJAVASunUnix programmer /O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569 (;O/ \/ \O;) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
