Getting xserver patches reviewed

[pcpa at mandriva.com.br]

Quoting Bernardo Innocenti <bernie at codewiz.org>:

> On 11/24/07 10:20, pcpa at mandriva.com.br wrote:
>
>>   The X Server also isn't as attractive, i.e. being a Kernel hacker is
>> usually considered cooler than being a X hacker.
>
> True, but I really can't see why...
>
> Clearly, the Linux kernel is in quite a good shape and
> is no longer *that* crucial for a wider adoption of Linux
> in the enterprise or in the desktop.
>
> The graphics subsystem, on the other hand, is really where
> Linux lags behind Windows and MacOS X.  Working on it,
> offers a lot of opportunity for improvement that will
> make a big difference.
>
> Non-techie users look at how the interface looks and behaves,
> and base their subliminal perception of the whole platform
> from these hints.  Being slowish or flickering, simply
> makes us look bad in their minds, and there are no benchmarks
> that can change their perception of Linux being slow and
> clumsy.
>
>
>> But if the X Server
>> magically becomes "mission critical" ready, lots of people would want
>> to have theirs names associated and start contributing, but this is very
>> unlikely to happen as the stability is heavily associated with fully
>> functional interfaces and graphics chips, that may either be buggy, or
>> the driver may contain bugs.
>
> The Linux kernel also deals with imperfect or undocumented
> hardware.  I suspect the huge number of developers is what
> makes drivers more mature.
>
> Now, I know I'll get tomatoes from both X and the kernel
> hackers for saying this, but I claim that the X codebase
> would be much *easier* to work with than the kernel.
>
> First, because it's single threaded.  Second, because it
> runs in userspace.  Third, there simply are fewer transversal
> concepts to deal with, such as paging, execution contexts,
> dma, software suspend.

  It's biggest problem is that any failure will usually
only allow remote access to the computer. And there isn't
any way to enter some kind of fallback/failsafe mode
without at least a server restart (this may be a cool
project to work on).
  A multi threaded X Server isn't mandatory, but for modern
cpus, the extra cpu time cost isn't a problem, and frequently
negligible, and allowing code to manage/wait the hardware
while the server is processing events or whatever would be a
"good thing" (other cool project).
  Nowadays there are fewer needs for something like this, but
there should be a way to cancel X requests, but multi threading
is an alternate solution. I remember one of my first experiences
with XFree86 and doing a wrong call to fill a rectangle of size
65535x65535, software rendering on a 386 with 8M ram...

> Despite its bad reputation, most of the code I've seen in
> the guts of the X server looks quite tidy and easy to work
> with.  There are a few exceptions, of course, but over the
> past two years I've seen lots of big cleanups happening.

  I find the hardest code to work on is hardware support,
because usually documentation isn't easily accessible. One
interesting project could be software emulation of video
chips, to allow easier development and debugging of drivers
(not a cool project, hardware vendors would love to
know you are reverse enginering theirs products...)

> If anyone still thinks the X server is hard to work with,
> please clone the git tree and start reading from main() on.
> No kidding.
>
> There are *lots* of open newbie tasks such as eliminating
> the excessive use of #ifdef's, switching to C99 types and
> undoing the questionable idea of hiding pointers behind
> typedefs.
  It should build with all available compilers, while I love
a lot of things from c99, I don't like C++ style comments
or declarations on the middle of code, but this is personal
preference :-) But requiring c99 would be a bit too much,
as it would put gcc out, as it is not fully compliant.
  Not sure if I understand the problem about typedefs for
pointers, given that reasonable/self documenting names
are used. I am more in favor of converting things like
long lists of #defines to enums, and using inline functions
to replace macros (i.e. allow typecheck and compiler
assistance as much as possible). Use macros only where
there is no other/better alternative.

> "X is hard and uncool" is just a heritage of the obscure
> XFree86 age.  It's not been true for a while.

  I find this comment, given the context, somewhat funny,
or stupid, sorry no offense, maybe it is my misunderstanding
of the english language :-)  I believe one of the major
problems with XFree86 is simply the fact that it was just
importing code from a permissive license for the core sample
implementation and working mainly on hardware support. X
Consortium was getting close to pretty much only aknowledgment,
but there was also some, close to childish :-) disputes from
XFree86 people, X Consortium and some people that were hoping
to make some major money from proprietary X Servers given the
big growth of Linux and FreeBSD market.
  I watched David Dawes take care, give responses, try to
triage it for other developers, etc, of all patches posted
in the XFree86 lists for like 10 years, almost alone. But
XFree86 had/has even less resources than freedesktop, and
save a few patches that some commiter would claim, everything
was done by a single man.


> I also had this fear that use of a permissive license would
> have made Xorg an easy prey of pillagers.  It was very much
> the case with Wine, until they finally switched to GPL.
>
> But these days, even companies in the business of proprietary
> software seem to be willing to contribute their code back to
> Xorg...
>
> So until the situation changes for the worse, there's no clear
> advantages to justify undergoing the endless religious wars
> that a license switch would take.

  Guess we should wait for any changes in the situation...
But, a cool project would be to start a X Server implementation
(or maybe even a new graphical architecture), using the GPL
license, or any other centralized license that developers trust.
I dont like having 9999 licenses in the code, I believe
developers of an open source project should be aknowledged as
the original author (with the power to relicense their own code),
but not like 2 or more copyright notices in the files. This is
a cool project, but very hard, others have tried and failed...

> Except, maybe, for the VNC case.  Did you have some specific
> piece of GPL software in mind?

  The main idea is to attract new developers, and allow
developers that prefer the gpl to use it. But there are a few
other components that are gpl (and in freekdestop git), like
avivo. Correct if I am wrong, but there are software/branches
like glucose where developers would prefer gpl.

> -- 
> \___/
> |___|   Bernardo Innocenti - http://www.codewiz.org/
>  \___\  One Laptop Per Child - http://www.laptop.org/

Paulo