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.
What is your metric? XFree86 is slow at what specifically? Provide some examples. >2. What is presented on the screen should always be consistent (i.e. no >flickering). Your screen flickers? If so, that would likely be considered a video driver specific bug, or possibly some other bug. That isn't a flaw of X, but rather a bug in a given video driver. >(3. It should be possible to configure XFree over a dialog that is intergrated >in Gnome and Kde.) I agree that a simple user friendly GUI config tool should exist. Such a tool should integrate into the user's desktop GUI of choice. The GUI config tool included with XFree86 is intended to be used on any system wether or not GNOME or KDE exists, and is thus based on Xt et al. In order for proper integration with GNOME, a GTK based tool needs to be created, and for KDE a Qt based tool. Preferably one tool with multiple front ends, to minimize duplication of effort/functionality. We're working on such a tool for GTK, but have no plans to make it Qt based (duplication of coding is a waste of resources), but since it is open source (redhat-config-xfree86) people are free to contribute to the codebase if they'd like a different frontend. >I'm sorry to say that and I really don't want to offend any people. Statements that start out apologizing for not wanting to offend people, generally go on to offend people. That said, I'm not offended, but others might be. >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. I don't see a huge problem with any of the things you've brought up above other than the configuration angle, and that is something which improves over time, and will likely consider to do so, and to become easier and easier. In order for it to happen, either someone who has a personal interest in making it happen for whatever their reasons are - volunteers to do it, and does it, or somebody funds it, or some company decides to do it themselves. I don't see anyone jumping up volunteering to write a user friendly GTK and/or Qt X configuration tool, so that leaves funded development. As I said above, we're writing a new config tool for GTK. Something like that takes time to implement and improve. The current development is coming along nicely, but it will be a while until all of the necessary features are implemented and friendly. >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. XFree86 is evolving slowly in some respects, and quite well in others. There are various reasons for that. I would put forth that the #1 reason for any slowness or perceived slowness of development, is simply due to the lack of people interested in developing X, and that lack of a linux-kernel like development environment where many hundreds, perhaps thousands of developers are quite active. X/XFree86 has a bit of a barrier to entry to new developers, as many people view it as one insanely huge pile of code that is impossible to understand and/or navigate. It can be daunting, but it is not impossible, and it takes a lot less time to start working with it than one might think. First step is to ignore the 98% of code that irrelevant in the scope of the portion of X you might be interested in working on. Another reason is that X development doesn't scale well IMHO as the number of developers or potential developers rise. The current XFree86 team is doing a good job at what they're doing, but if the number of contributing developers to XFree86 was to double or triple, the patch queue's would only lengthen, simply because the XFree86 team is quite busy doing what they do best already. The lack of a bug tracking database also enters into this problem IMHO, but that is another discussion. I'm not sure how the scalability issue can be addressed, but in order to get more developers working on the code, some sort of effort needs to be made by people who are interested in attracting more developers, to help minimize the barriers to developer entry, and create developer FAQ's, debugging FAQ's, and other developer useful information. I try to help would-be developers get started as much as I can, and I'm sure many others do too, but it is itself time consuming too. The more community involvement we've got, the better IMHO. >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. It isn't apparent where your 5% comes from (other than randomly chosen from thin air), but I think it is grossly inaccurate. I also believe that the above statements are not based much in fact really. There are some cases where the X11 protocol slows things down, however with todays computers, it is mostly moot. It is quite difficult to tell the difference really. And all of the slowness people might see in a given application or desktop environment, are not due to X11 protocol being in the middle. It can be due to toolkit libraries being innefficient, or one of 1000 other things. The solution is to profile software and find the bottlenecks, then improve the code to remove those bottlenecks or reduce them. >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. It is hardly ancient. Ancient implies it isn't used. The X11 API has existed this long exactly because of its extreme flexibility. Some might argue it was overdesigned, perhaps, but it has stood the test of time. And yes, extensions exist to allow adding functionality to X without breaking compatibility with the core protocol. Quite a good design idea actually. >But this way X gets more and more complex. Adding new features to ANY software makes it more complex. It doesn't matter if it is X11 protocol, or Microsoft Windows API. You generally don't get more features and flexibility by removing code. You must add code generally, and adding that code requires either making a new API, or extending an existing one. What's more is that the new X extensions generally do something NEW that wasn't available before, so they are merely adding new optional features to the existing API. They do not break the API just to add features. There is no reason to. >And why are the 2d graphics drivers in users space while the 3d >drivers are in kernel space? First of all, you're wrong. But it is obvious you don't understand driver programming or you would not have asked that in the first place really. Graphics drivers do not belong in the kernel. The drivers are userland because they do not NEED to be in the kernel, and there is no benefit to putting them in the kernel. Any hardware needing to do DMA, requires a kernel portion, because DMA can only be done in the kernel. Without having the DRM, it would be impossible to do safe secure DMA in video drivers. DMA is a kernel thing. Interrupt handlers are also a kernel thing. So any portion of a video driver requiring using DMA or IRQ's must be in the kernel, and some API set up for userland code such as XFree86 to take advantage of it. The DRI was originally designed for the purposes of 3D acceleration done in a safe and secure manner using DMA, et al. however the DRI is not at all limited to 3D. If you're using an ATI Radeon for example, and have DRI enabled in XFree86, then your 2D acceleration is ALSO using the DRM. The kernel comes into play any time DMA is being used. Hardware such as the Radeon can do 2D accleration with or without using a DMA based approach. Anything that is not related to doing DMA et al. does not belong in the kernel. >As a result of this complexity the developers working on XFree >are less efficient and it also keeps new developers from joining >this project. Your perceptions are wrong about the above. Face it, video device driver programming is not simple. DMA is not simple. Kernel programming is not simple. Working on 2D drivers isn't that complex if someone is interested enough, and has some programming skills, and a general knowledge of bit twiddling hardware. Working with the kernel side of things requires a knowledge of the kernel. In the case of 3D drivers et al., it requires knowledge of various other areas as well, such as OpenGL internals. Video driver development is a complex topic, due to all of the complexities involved _period_, not because of the particular implementation of XFree86 and the kernel, and the design of the current system we've got. If anything, I would say that the lack of developers is due to the lack of people with both the skill, and the time with which to get involved. >What I want to suggest is to start from scratch and design a >new, clean and modern windowing system without any legacy. And you're not the first to do so. There are many people who have stated just that in the past. Generally, they do not understand X at all, and set out to reinvent the wheel, rather than making the wheel better. There is the Berlin Project, and there is another project linuxgfx which set out to reimplement X with a fastpath to avoid protocol encode/decode for the local server case. Both of these projects (and likely many more) have gotten basically nowhere. Reinventing the wheel from scratch is 10000 times more complex than improving the current X11 system. Why? Because you have to learn all of the same mistakes yourself that existing X developers already know. People tend to simplify systems by making them do what _they_ want/need/see as relevant, and ignoring what others want/need. Then over time that "new" system gets hacked and kludged by various people to do more and more what the existing system does. In the end, you've reinvented the wheel. But, if there isn't enough people working on X currently, there would be much less people available to reinvent it, so the idea is fruitless IMHO. Nonetheless, feel free to start a new project on sourceforge to do so if you think it is a meritable idea. Or just take over one of the many other projects that have been started and dropped. >I know this would be a pretty radical cut, but I personally >don't see any alternative to overcome the current problems of >XFree. Yes, there are problems with XFree86/X11, and people are working on them. There are finite people, and finite resources. We don't really need or benefit from people pointing out the flaws of the system (or percieved flaws), but we do benefit from people writing code and volunteering to make the system better. Anyone working on X right now, is probably quite unlikely to consider workign on a new graphical system from scratch, which makes the pool of people quite small who would venture into such an idea. Volunteer to help fix the problem: - extend X to add features that are not present but required or would-be-nice - write new software to make using X/configuring it, etc easier - fix bugs in the existing code - write new video drivers, or improve existing ones, fix driver bugs. - write new documentation, or complete existing but incomplete documentation. - advocate helping people becoming involved - write FAQ's and other helpful guides to help new developers - help beta test the code, use CVS, etc. so bugs can be found and fixed faster. >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. The main problem with a new graphics API is that it is irrelevant and unnecessary. We've got an API already that is just fine, and anything it lacks, it is flexible enough to be sanely extended. Who wants to go and rewrite every app out there to use a new API? There are tonnes of efforts already to write new API's, and nobody has jumped to support them in a large manner yet, nor are they likely to. X11 and XFree86 are here to stay, and nothing is likely to challenge that IMHO. People can grumble about it's current shortcomings and become part of the problem, or they can participate in writing code or documentation, or otherwise contributing constructively and usefully, advocating improvements, testing, etc., and be a part of the solution. My $0.02 -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
