Re: [Xpert]Dislpay beffer/Frame buffer
On Sat, 13 Jul 2002, Preetham wrote: Hi All: I was looking thru the source code of the XFree86 server. I was wondering if it was possible to change the background color/image of the Client Display. Does the program xsetroot do what you want ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
On Thu, 2002-07-11 at 22:27, Kevin E Martin wrote: I've just checked in a large patch from ATI. Here's the CHANGELOG entry: 199. ATI patch to: - Fix Dell OEM VE card support - Add better clone mode support - Fix large panel (= 1600x1200) detection and initialization problems - Remove PanelSize and CrtScreen options since they are no longer needed with new CloneMode and improved flat panel support Hmm, with XF86-4.2 I had to use CrtScreen to get a display, now I had to set: Option CloneDisplay 1 Is that the intended way to do it? Without either one, I don't get a display on my CRT (which is my only monitor, somehow the card thinks I have a flat panel which I don't have). Nils -- Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg // +49.7152.209647 [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Ever noticed that common sense isn't really all that common? signature.asc Description: This is a digitally signed message part
Re: [Xpert]Reg. X Security Extensions
On Tue, Jun 04, 2002 at 07:56:03AM -0700, [EMAIL PROTECTED] wrote: Either way, we have (at least) three potential uses for the extension: 1) shared resources like projectors or 2) when using groupware among relatively untrusted people. 3) remote applets. I don't know exactly how the Security-extension works, but it would be nice if you could tunnel X over ssh without worrying about wether the security of the remote machine has been compromised. Right now such a tunnel could easily be used to eavesdrop on your keyboard for example. Could the Security-extension be used to improve this? /AE ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
On Sun, 2002-07-14 at 13:57, hy0 wrote: On Thu, 2002-07-11 at 22:27, Kevin E Martin wrote: I've just checked in a large patch from ATI. Here's the CHANGELOG entry: 199. ATI patch to: - Fix Dell OEM VE card support - Add better clone mode support - Fix large panel (= 1600x1200) detection and initialization problems - Remove PanelSize and CrtScreen options since they are no longer needed with new CloneMode and improved flat panel support At least Option PanelSize would still be useful for systems where we can't determine the panel parameters yet. Current Radeon driver supports two kinds of panel: TMDS panel (usually used for desktop, named as DFP in the driver for some legacy reason) and LVDS panel (usually used for laptop, named as LCD in the driver). The TMDS panels should be DDC capable, if not, the BIOS won't even be able to bring them up to text mode. For this kind of panel, the radeon driver will try to do DDC detection first. If it fails for some reason, the driver will used EDID data detected by BIOS. With the DDC info, the driver can figure out the panel size and bring it up automatically. The laptop (LVDS) panels usually are not DDC capable (some new ones are). The panel size and timing information are hard coded into video BIOS and radeon driver will use it to bring the panel up. The only potential problem here is that some custom version of BIOS doesn't follow the rule and put the panel info to a different place. I haven't come across such a laptop yet and would like to know if someone has one. Not every machine has a BIOS. Only knowing panel size (together with VESA timings) usually is not good enough to bring a LVDS panel up properly. Even with the correct modeline, it's better to know other things (like power delay) to safely turn the panel on/off. Let user to specify panel size can be error prone. Anyway, if there are people out there really requiring this option, I can put it back. I think it's still needed as a fallback until automatic detection truly works everywhere. Which might not be far away though, more below... As for non-native modes (resolution lower than panel size), by default, radeon driver will use the internal ratio matrix expansion (RMX) unit to scale the display down. It works not only for all standard VESA modes, it'll work also for any mode between 320x200 and panel size, for example 600x500. That was just an example why using virtual resolution as panel size doesn't work in general. - Add DDCMode option to detect and use DDC modes - Add PanelOff option to disable panel on laptops - Fix corrupted console problem - Other misc fixes (#A.1043, Hui Yu@ATI). I'd like get some feedback on how it works for others with both desktop and laptop Radeons. Doesn't quite work on a Titanium PowerBook III (without Option UseFBDev, with a 1280x854 modeline obtained by radeonfb via EDID which works fine with that option). There are flickering lines on the right side. Is the DDC detection OK? No, because we don't have a way to determine the display type yet (do you happen to know a way which doesn't require a BIOS?). If I hardcode info-DisplayType = MT_LCD; info-DDCType = DDC_DVI; DDC works (nice!), but there's still the same flicker. Option DDCModes isn't used, but I assume not providing any Modes is mostly the same. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Reg. X Security Extensions
On Sun, 14 Jul 2002, Andreas Ehliar wrote: I don't know exactly how the Security-extension works, but it would be nice if you could tunnel X over ssh without worrying about wether the security of the remote machine has been compromised. Right now such a tunnel could easily be used to eavesdrop on your keyboard for example. Could the Security-extension be used to improve this? After some thought I see the problem, so you probably know more about the security extension than I do. Since the tunnel isn't a single X client, it might not be easy to use the extension to tie the tunnel down. (Assuming that the extension works) you could start Xnest with no access to other clients, and run an ssh tunnel from the Xnest server instead of the main one. That ought to make Xnest into a sandbox for the compromised machine to play in. For all I know, there may be a way to config the security extension to block the tunnel. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
PanelSize CrtScreen CloneDisplay CloneMode What are all theese options ? In what section are they used ? Can you give me a sample XF86config and a link to the convenient documentation - Remove PanelSize and CrtScreen options since they are no longer needed with new CloneMode and improved flat panel support Hmm, with XF86-4.2 I had to use CrtScreen to get a display, now I had to set: Option CloneDisplay 1 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Cannot start with theater
With theater_drv module present Xfree starting stops after loading theater module and X task is looping... root 9552 9551 70 15:53 ?00:01:26 /etc/X11/X :0 -deferglyphs 16 If I delete theater_drv module, I can start X autologin session Sony Vaio GRX316 / ATI Radeon mobility 7500 / Display 1600x1200 installed Mandrake RPMS: XFree86-100dpi-fonts-4.2.0-16mdk XFree86-server-4.2.0-16mdk XFree86-75dpi-fonts-4.2.0-16mdk XFree86-4.2.0-16mdk XFree86-xfs-4.2.0-16mdk XFree86-libs-4.2.0-16mdk XFree86-devel-4.2.0-16mdk ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Frame Buffer
Hi All, The frame buffer code sits in the mfb/cfbXX folder. Is there any documentation which explains how this Frame Buffer is writen and how the Client Program Window is captured. Appriciate the help. Thanks, Preetham.
[Xpert]Strange compile problem
I am having a problem compiling XFree CVS on my PC. I've tried several compilers gcc 2.95.4, 3.0.4, and 3.1 and they all produced this error. Does anyone have a clue as to what could be the problem? root@pc1:/drives/work/src/XFree86-cvs/xc # make World Building Release 6.6 of the X Window System. I hope you checked the configuration parameters in ./config/cf to see if you need to pass BOOTSTRAPCFLAGS. Sun Jul 14 13:05:24 EDT 2002 cd ./config/imake make -f Makefile.ini BOOTSTRAPCFLAGS= CC=/usr/gcc-2.95.4-ds10/bin/gcc clean make[1]: Entering directory `/drives/work/src/XFree86-cvs/xc/config/imake' rm -f ccimake imake.o imake rm -f *.CKP *.ln *.BAK *.bak *.o core errs ,* *~ *.a tags TAGS make.log \#* rm -f -r Makefile.proto Makefile Makefile.dep bootstrap rm -f imakemdep_cpp.h make[1]: Leaving directory `/drives/work/src/XFree86-cvs/xc/config/imake' make Makefile.boot make[1]: Entering directory `/drives/work/src/XFree86-cvs/xc' cd ./config/imake make -w -f Makefile.ini BOOTSTRAPCFLAGS= CC=/usr/gcc-2.95.4-ds10/bin/gcc make[2]: Entering directory `/drives/work/src/XFree86-cvs/xc/config/imake' making imake with BOOTSTRAPCFLAGS= and CROSSCOMPILEFLAGS=-DCROSSCOMPILEDIR= in config/imake /usr/gcc-2.95.4-ds10/bin/gcc -o ccimake -DCROSSCOMPILEDIR=\\ -O -I../../include -I../../imports/x11/include/X11 ccimake.c if [ -n ] ; then \ /cc -E `./ccimake` \ -DCROSSCOMPILE_CPP imakemdep.h imakemdep_cpp.h; \ else touch imakemdep_cpp.h; fi /usr/gcc-2.95.4-ds10/bin/gcc -c -O -I../../include -I../../imports/x11/include/X11 `./ccimake` imake.c /usr/gcc-2.95.4-ds10/bin/gcc -o imake -O -I../../include -I../../imports/x11/include/X11 imake.o make[2]: Leaving directory `/drives/work/src/XFree86-cvs/xc/config/imake' rm -f ./config/makedepend/Makefile.proto ./config/imake/imake -I./config/cf -s ./config/makedepend/Makefile.proto -f ./config/makedepend/Imakefile -DTOPDIR=../.. -DCURDIR=./config/makedepend In file included from Imakefile.c:28: config/cf/Imake.tmpl:1936: macro Concat3 requires 3 arguments, but only 1 given config/cf/Imake.tmpl:1936: warning: extra tokens at end of #include directive config/cf/Imake.tmpl:1937: ,TopLevelProject,.rules: No such file or directory config/cf/Imake.tmpl:1949: macro Concat3 requires 3 arguments, but only 1 given config/cf/Imake.tmpl:1949: warning: extra tokens at end of #include directive config/cf/Imake.tmpl:1950: ,TopLevelProject,.tmpl: No such file or directory ./config/imake/imake: Exit code 1. Stop. make[1]: *** [config/makedepend/Makefile.proto] Error 1 make[1]: Leaving directory `/drives/work/src/XFree86-cvs/xc' make: *** [World] Error 2 Fred ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Is the XFree development stuck in a dead end?
Hello, in recent years many people were talking about Linux on the desktop. However, before there is any real chance that this could happen a few fundamential problems in XFree must be solved. These are: 1. XFree is far too slow. 2. What is presented on the screen should always be consistent (i.e. no flickering). (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) I'm sorry to say that and I really don't want to offend any people. But I've hardly seen any progress regarding these problems during the last two years and I don't see any way how this could change in the next two years. XFree is evolving very slowly despite the fact that some of the best developers are working on it. I think the reason for that is that XFree is far more complex than necessary for its intended job. I know there have been countless discussions on the X messaging system, but most of them missed the point. That is that such a messaging system introduces an enormous amount of complexity. As far as I know the only reason for having the X messaging system is the remote display feature. But I guess that less than 5% of the XFree users are actually using this feature and there are already other solutions like VNC available. Another source of complexity comes from the ancient, more than 10 years old X API. Many people argue that one just has to add new extensions to keep XFree up to date. But this way X gets more and more complex. And why are the 2d graphics drivers in users space while the 3d drivers are in kernel space? As a result of this complexity the developers working on XFree are less efficient and it also keeps new developers from joining this project. What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. I know this would be a pretty radical cut, but I personally don't see any alternative to overcome the current problems of XFree. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. Cheers Lukas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
1. XFree is far too slow. I don't know what your terms of comparison are, but for example return to castle wolfenstein on same hardware runs really faster than on windows, with maximum settings. Dunno if this means anything. 2. What is presented on the screen should always be consistent (i.e. no flickering). It is already? (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) Someone should write it. Indeed I think there are: I personally use debian, but Mandrake, Suse and RedHat users continuously say that their distribution can do everything graphically. I think the reason for that is that XFree is far more complex than necessary for its intended job. I think that this complexity allows me to run two X server on two 486, a font server on pentium and applications on an athlon. No other windowing system can do this AFAIK. But I guess that less than 5% of the XFree users are actually using this feature But it happens they use it. And anyone who has two computer connected with ethernet and some kind of unix has needed this sometimes. and there are already other solutions like VNC available. Which is based on the xfree86 architecture AFAIK. Another source of complexity comes from the ancient, more than 10 years old X API. Many people argue that one just has to add new extensions to keep XFree up to date. But this way X gets more and more complex. It's not true. You just learn what you need. What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. There are already. Go and see berlin, for example, or microwindows, or directfb, which appears one of the coolest. There are really MANY others. Have a look on google, you'll find'em. I don't see the point: this is the xfree86 project, why should they change everything? Then it would be another project. I personally don't see any alternative to overcome the current problems of XFree. I don't see real problems in XFree, and think that one of the best features of X is the networking capabilities. Indeed, have a look to how easy is to have xinerama on two different video cards. Do this with windows or macos. It's hard, if not impossible at all. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. It's already planned for MANY other windowing system. By now, I think that X cannot get out of some of its limitations, but its implemented features are what many people needs. Those who can't bear the limitations, should join one of the existing projects, but he/she will realize that the first thing he/she'll be missing will be ... X, and that mantaining backward compatibility is a challenge. Sorry for my bad english, and hope to have clarified your ideas a bit :) Cheers Lukas Bye Vincenzo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002, Lukas Molzberger wrote: Hello, in recent years many people were talking about Linux on the desktop. However, before there is any real chance that this could happen a few fundamential problems in XFree must be solved. These are: 1. XFree is far too slow. No it isn't. Your apps are stupid or the drivers you are using are under accelerated. 2. What is presented on the screen should always be consistent (i.e. no flickering). (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) Talk to the Gnome and KDE people then. I'm sorry to say that and I really don't want to offend any people. But I've hardly seen any progress regarding these problems during the last two years and I don't see any way how this could change in the next two years. XFree is evolving very slowly despite the fact that some of the best developers are working on it. I think the reason for that is that XFree is far more complex than necessary for its intended job. You say it's too complex and then you say we need more features? I know there have been countless discussions on the X messaging system, but most of them missed the point. That is that such a messaging system introduces an enormous amount of complexity. As far as I know the only reason for having the X messaging system is the remote display feature. But I guess that less than 5% of the XFree users are actually using this feature and there are already other solutions like VNC available. Another source of complexity comes from the ancient, more than 10 years old X API. Many people argue that one just has to add new extensions to keep XFree up to date. But this way X gets more and more complex. And why are the X is highly extensible by design. It's far less complex than alternative window systems like MS Windows or OS-X and is probably more extensible. 2d graphics drivers in users space while the 3d drivers are in kernel space? You are mistaken. 3D drivers are not in kernel space. OpenGL is in user space in every OS I can think of. As a result of this complexity the developers working on XFree are less efficient and it also keeps new developers from joining this project. What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. I know this would be a pretty radical cut, but I personally don't see any alternative to overcome the current problems of XFree. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. I think you have the wrong mailing list. XFree86 is an implementation of the X-Window system. The key phrase here is the X-Window System. XFree86 is headed in the directions of an X-Window compatible system, meaning we intend to extend XFree86 well beyond the base sample implementation, and in many regards we have done this already, but we have no intention of dropping what you call legacy support. As far as development being stuck, no, I don't think so. It's just that the people who know enough about anything to get things done are very few. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002, Lukas Molzberger wrote: I know there have been countless discussions on the X messaging system, but most of them missed the point. That is that such a messaging system introduces an enormous amount of complexity. As far as I know the only reason for having the X messaging system is the remote display feature. But I guess that less than 5% of the XFree users are actually using this feature and there are already other solutions like VNC available. Fully realizing that I'm probably in the 5%, remote display is always a sticking point for me with MS-indows machines. Especially when just before you're talking about making graphical tools for configuration. If I can't display the tool remotely and have to go from desk to desk, I might as well be using MS-Windows. :) The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. I had this though just the other day. I think in the long run, you're right, as long as there's some method of remote display. Of course, I look at things as an administrator/support person in a large installation. Remote display is much nicer, for using a graphical config on someone desk (rare), but moreso so people can run matlab (for example) on the 8-cpu 2GB RAM machine in the lab with the display on their desk. -- Matt Piechota ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
Le lun 15/07/2002 à 01:39, Nick Name a écrit : (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) Someone should write it. Indeed I think there are: I personally use debian, but Mandrake, Suse and RedHat users continuously say that their distribution can do everything graphically. Better yet, XFree shouldn't need configuration at all with modern hardware: config is just needed for some old un-probable chips, and some settings such as resolution, depth, etc. (which should be settable on the fly, BTW) I personally don't see any alternative to overcome the current problems of XFree. I don't see real problems in XFree, and think that one of the best features of X is the networking capabilities. Indeed, have a look to how easy is to have xinerama on two different video cards. Do this with windows or macos. It's hard, if not impossible at all. Is that a joke ? Did you ever try to set up a second gfx card and monitor under Mac OS ? It's a breeze, just point'n'click. Whereas in X, you have to hunt for the Xinerama HOWTO and mess with the config file. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
Lukas, Although you may have some valid concerns I think you're missing the big picture. On Mon, Jul 15, 2002 at 01:11:17AM +0200, Lukas Molzberger wrote: Hello, in recent years many people were talking about Linux on the desktop. However, before there is any real chance that this could happen a few fundamential problems in XFree must be solved. These are: 1. XFree is far too slow. 2. What is presented on the screen should always be consistent (i.e. no flickering). (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) First, it isn't X speed which is stopping the desktop on Linux: nowadays people use workstations that are incomparably faster to the machines where X was initially developed. I really don't understand point no 2. Nothing is stopping 3 from being accomplished. (You're also forgetting that to have X configured on a dialog, you need X running and configured on the first place...) [...] I think the reason for that is that XFree is far more complex than necessary for its intended job. I know there have been countless discussions on the X messaging system, but most of them missed the point. That is that such a messaging system introduces an enormous amount of complexity. As far as I know the only reason for having the X messaging system is the remote display feature. But I guess that less than 5% of the XFree users are actually using this feature and there are already other solutions like VNC available. You're forgetting that one of the purposes of the messaging system is to provide a physical seperation between the application the the GUI itself. It will always be need some kind of messaging to accomplish that - either through a socket, an IOCTL, or shared memory - the information has to be encoded somehow. Another source of complexity comes from the ancient, more than 10 years old X API. Many people argue that one just has to add new extensions to keep X is used as a low level API - it assumes a toolkit layer is used upon it, such as GTK, or QT. XFree up to date. But this way X gets more and more complex. And why are the 2d graphics drivers in users space while the 3d drivers are in kernel space? 3D drivers are mostly in the user space. A 3D driver consist of an implementation of the OpenGL state machine on the client application space (that fills DMA buffers), a very thin layer on ther kernel (that sends the buffers to the hardware), and the 2D driver on X (which setup modes and other things). The kernel isn't the right space for lot of stuff required for 3D (such as floating point ops e.g.). As a result of this complexity the developers working on XFree are less efficient and it also keeps new developers from joining this project. What holds development is the paramount of chips supported by X, which result in an huge ammount of maintainance work (testing, debugging, updating). To make a 2D driver one doesn't really need to go into the detail of the messaging encoding or anything like that... What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. I know this would be a pretty radical cut, but I personally don't see any alternative to overcome the current problems of XFree. From the contact I had with X I've come to the conlusiong that X gives an effective answer to lot of the issues involved in a GUI. Things could had been done differently, but I doubt they would be much better. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. As said before, most applications don't target X but a higher-level toolkit. You already find GTK and QT on other platforms. GTK can even target the linux framebuffer devices, which should be somthing you ought to be interested in. I think that the biggest drawback in X is its development model. The way as it's done doesn't scale. It doesn't scale with supported hardware, it doesn't scale with the number of features, and it doesn't with the number of people willing to work on it. José Fonseca ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On 15 Jul 2002 01:56:41 +0200 Xavier Bestel [EMAIL PROTECTED] wrote: Is that a joke ? Did you ever try to set up a second gfx card and monitor under Mac OS ? It's a breeze, just point'n'click. Whereas in X, you have to hunt for the Xinerama HOWTO and mess with the config file. Ok, sorry. I just made THE mistake: speaking 'bout what I don't know. Sorry. But really, I've tried to simply install a second video card, different from the first, in win98. Freeze. Stop. No way, I had to remove the card, and manually remove the driver... still I can't remember how I got out of that mess. In the same period, with X, I could do everything I want, even get two 3d games running at the same time, one on a matrox, and another on a s3/3dfx pair... simple: use two X servers :) Sorry I will never speak 'bout mac again :) Vincenzo ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On 2002-07-15 at 01:11 +0200, Lukas Molzberger uttered: | Hello, | in recent years many people were talking about Linux on the desktop. | However, before there is any real chance that this could happen a few | fundamential problems in XFree must be solved. These are: Linux on the desktop -- for your average, casual computer user -- admittedly is still a long way off. I'm implying that, OMG (and God forbid) one actually needs a functional brain to make any real use of Linux and a lot of know-how to make it their OS of choice. As we say, Linux is user friendly. It just tends to be picky about its freinds. | 1. XFree is far too slow. Compared to...?? Windows? OSX? A VW Beetle? Compared to what? | 2. What is presented on the screen should always be consistent (i.e. no | flickering). Elaborate. | (3. It should be possible to configure XFree over a dialog that is intergrated | in Gnome and Kde.) | This is up to the Gnome KDE people, ie, Gnome and KDE are third parties. The XFree86 team has nothing to do with integrating config tools into your desktop of choice; this is up to the maintainers of your desktop. [snip] | introduces an enormous amount of complexity. As far as I know the only reason | for having the X messaging system is the remote display feature. But I guess | that less than 5% of the XFree users are actually using this feature and | there are already other solutions like VNC available. | Another source of complexity comes from the ancient, more than 10 years | old X API. Many people argue that one just has to add new extensions to keep [snip] 5%? I'm sure the percentage is far higher than you suspect, although I -- like you -- have no authoritative source at hand. Walk into any large commericial institution -- or any place other than the bedroom of a dribbling 14-yr old -- that uses some variant of Unix as a primary platform to get their job done. With my hand on God I will guarantee that every admin and every other such individual that uses and abuses X on a daily basis would not be able to function efficiently or cheaply without the use of remote displays. It's rather nice to be able to ssh to a box half way around the world and run an X app, not to mention a helluva lot cheaper than flying half way around the world. Cheers. krjw. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002 01:13:19 +0100 José Fonseca [EMAIL PROTECTED] wrote: to have X configured on a dialog, you need X running and configured on the first place Great! :))) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002, Lukas Molzberger wrote: What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. And what evidence do you cite that this new system will be faster, smaller, cleaner, or better? Designing a windowing system is *not* easy. Even Apple, a luminary in user interface design, created a dog slow, bloated pig of a windowing system to start. Mac OS/X is getting better, but it's still sluggish. There are two important things to keep in mind: First, XFree86 only recently became the dominant implementation of X. Before that, any extensions made it incompatible with any of the other X implementations. That has become less of an issue as XFree86 continues to gain momentum and market share. Consequently, XFree86 can now set the standard rather than react to the standard. Second, Windows, MacOS, and even VNC developers were *paid* to develop these windowing systems. Few of the XFree86 developers get paid full-time to develop XFree86. If you really want to help accelerate development, get these folks some funding so that they can develop XFree86 full-time. -a ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
Not every machine has a BIOS. In that case, there are a few more things (in addition to panel size) we need to worry about before it can work reliably. Things like PLL ref clock, display type ... are all derived from video BIOS image. As for non-native modes (resolution lower than panel size), by default, radeon driver will use the internal ratio matrix expansion (RMX) unit to scale the display down. It works not only for all standard VESA modes, it'll work also for any mode between 320x200 and panel size, for example 600x500. That was just an example why using virtual resolution as panel size doesn't work in general. Virtual resolution should not be used as panel size, it never has. Is the DDC detection OK? No, because we don't have a way to determine the display type yet (do you happen to know a way which doesn't require a BIOS?). If I hardcode info-DisplayType = MT_LCD; info-DDCType = DDC_DVI; DDC works (nice!), but there's still the same flicker. Option DDCModes isn't used, but I assume not providing any Modes is mostly the same. I took a shortcut in determining the display type -- thru video BIOS settings. It works in most of cases, but not really reliable as seen in your case (I have comments on this inside the code, I think). A more proper way to enumerate through all DDC types and probe potential connected monitors. Once you have EDID data, you can derive its display type. This should work in your case. But, in general, you cannot conclude there is no display connected if the DDC detection fails. A lot of laptop panels simply are not DDC capable, the panel info is hardcoded into the BIOS image (this may not apply to you). The combination of two methods will make the auto-detection more reliable. As for the flicker problem, maybe you can print out all PLL parameters and CRTC settings used by driver and compare them with the settings used for FBDev. If the driver cannot access BIOS, it'll use the hardcoded PLL parameters, I'm not sure if they are correct in your case. Hui ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Is the XFree development stuck in a dead end?
Someone should write it. Indeed I think there are: I personally use debian, but Mandrake, Suse and RedHat users continuously say that their distribution can do everything graphically. Better yet, XFree shouldn't need configuration at all with modern hardware: config is just needed for some old un-probable chips, and some settings such as resolution, depth, etc. (which should be settable on the fly, BTW) Correct me if I'm wrong (I'm new to Unix): Yeah, but then you'd need all that software support stuff saved on your computer and included in you Kernel. That's one of the major reasons why I'm getting out of Windows -- too much stuff I don't need loading up. I figure someone could write a program to probe devices and figure out their settings, but I don't want it. I don't install hardware everyday (hardly every year), so why would I want all that stuff loaded into my machine everytime I run it? -James Turnbull ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Xpert digest, Vol 1 #2013 - 11 msgs
From: Lukas Molzberger [EMAIL PROTECTED] (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) I think what he means here is resizing the screen *without* going to a virtual screensize. One can resize the screen via keys or via a GUI (e.g. wmxres), but the problem is that it's a *virtual* screen then, and, instead of acting like a full screen, one scrolls around on the larger virtual screen. What would be nice is a way to have X not make the new screen res virtual, but actual. :) BTW, what Xlib calls are involved to change screen resolution? I couldn't find one in the manpages, so far as I can tell. -Joseph -- [EMAIL PROTECTED] We're moving toward a world where all the capabilities of the Internet are reprocessed through a single filter, with Microsoft's business plan behind it. Mozilla's Mitchell Baker, http://news.com.com/2100-1023-941926.html ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Radeon patch testing
Hmm, with XF86-4.2 I had to use CrtScreen to get a display, now I had to set: Option CloneDisplay 1 Is that the intended way to do it? Yes. This option is supposed to be on by default. Since that part of code is not well tested, it's default off for now. Anyone who wants to mirror the 2nd display should turn on this option. Without either one, I don't get a display on my CRT (which is my only monitor, somehow the card thinks I have a flat panel which I don't have). It's strange. Are you using one of mibile cards (M6/M7)? From what I know, only mobile cards for internal qualification behave like this. The retail mobile cards are usually built into a laptop which has a LCD connected. Hui ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
