Whither X?

[Peter Jeremy]

Am I the only person who thinks the X.Org Project has lost its way (or
at least lost sight of its user community)?  Ever since X.org 6.9,
successive releases of X.org have provided regressions and POLA
violations.

Whilst the X.Org Project has been adding native support for newer
GPUs, it has been doing so at the cost of basic functionality: If you
happen to be one of the lucky ones who gets the incantations and
sacrifices right then you might have accelerated 3D on your new
graphics card.  More likely, it will hang your system if you try to
use it, or you won't be able to use X at all - even on cards that used
to work.

The transition from X.org 6.9 to X.org 7.0 added no new functionality.
It just split X into several hundred pieces and massively increased
the build time.  The justification was that bugs in one component
could be corrected by just rebuilding that component.  The reality has
been that the concepts of regression testing and integration testing
have gone out the door and new versions of arbitrary components (which
may or may not be API/ABI compatible with previous versions) are just
dumped on the user community.

The biggest regression in 7.0 was the switch from imake to GNU
configure.  Whilst GNU configure is promoted as a portability aid,
anyone who attempts to port code to (eg) FreeBSD or Solaris will
quickly discover that the reality is completely the opposite - the
input language is so arcane it needs two levels of pre-processing by
custom tools before it can be handled by standard tools and it
generally provides a long-term, distributed memory for disinformation
(eg "the native object format for FreeBSD is a.out and objformat can
be used to check for ELF").  The appallingly bad performance of
configure (for some X components, configure takes 4-5 times as long to
run as the actual compilation), combined with the massive increase in
the number of pieces caused a massive increase in compilation time.
The FreeBSD performance was further worsened by the (known) poor
scaling of the packaging tools to large numbers of ports and
dependencies (stock xorg currently has ~250 build dependencies and
over 200 run dependencies).

X.org 7.1 was never commited into the ports tree and I don't have
any record of specific problems with X.org 7.2.

X.org 7.3 introduced another major set of regressions:
- hard-wired modelines that can't be disabled without patching the
  source code (though this may be been broken earlier than 7.3).
- xdm config files installed into the wrong directory
- Broken files installed into /usr/local/lib/X11/xdm
- Corrupt xdm/Xresources file installed
- Display corruption when VTY/X11 switching on an ATI Radeon XPRESS 200M
- system clock occasionally loses a second during a VTY/X11 switch
- DPMS display off/on can corrupt display on ATI X200M.
- Use-after-free error causes Xserver to consistently abort() on exit
- Keyboard LEDs stopped working
- Scroll wheel stopped working
- HW cursor and DPMS broken on MGA G550
- excessive gettimeofday() calls due to a configure bug

Many of them were subsequently fixed and some were problems in the
FreeBSD ports rather than the underlying X.org but it is unfortunate
that the code was committed to the ports tree before being fixed.

Somewhat after X.org 7.3 was committed, having followed the pain felt
by many others as well as having experienced problems myself, I wrote:
"Having followed X within FreeBSD from XFree86 3.1.2 through to X.org
7.3, I can safely say that X.org 7.3 is by far the worst version as
far as POLA violations and regressions are concerned."

Well, that was before X.org 7.4 was released - which set a new record
for brokenness.

So far, X.org 7.x releases have focused on the server.  X.org 7.4 adds
new client side functionality - with a new "Generic Event Extension".
Unfortunately, this was done before server support was ready - leading
to a stream of warnings that can't be suppressed.  (I had a look at the
code and it is carefully crafted to make suppression almost impossible).

Another new misfeature in X.org 7.4 is the use of dbus/hal.  I have
yet to find any rationale for using hal in an Xserver - hot-plugging
both keyboards and mice "just works" in FreeBSD and I've yet to see
any equipment that allows hot-plugging graphics cards.

Whilst trying to rebuild just parts of X, I've also discovered that
the dependency checks are wrong - eg, I can uninstall libxcb and all
its dependencies.  When I then try to build xorg-server, it dies
inside the graphics/dri configure script reporting that x11-xcb is
missing.  This shouldn't happen.

There were the usual POLA violations:
- xdm, xconsole, xload, xlsfonts, xmag (and others) were silently
  dropped from x11-apps
- The "DontZap" default was quietly reversed, meaning Ctrl-Alt-BS no
  longer works by default.
- Only one graphics card is supported.

But the worst problem is that for many people, including myself, the
Xserver just doesn't work at all.  For the first time since at least
FreeBSD 2.x, FreeBSD 7.2 has shipped with an Xserver that won't work
for a significant number of people (as the mailing lists are beginning
to reveal).

The most common failure modes I've seen is that the Xserver just
presents a completely blank screen - and all you can do is kill the
Xserver.  On occasion, I have managed to make the Xserver crash with
unresolved symbols (this appears to be the result of incorrect and/or
inadequate dynamic linkage information in some modules resulting in
required shared objects not being loaded in some cases).

And this occurs across a variety of hardware - i945, ATI X200M, ATI
Radeon HD2400, with both FreeBSD 7.2-stable and recent 8-current on
both i386 and amd64.  I've tried building xorg from scratch both with
and without HAL.  I've tried installing the Xorg packages that shipped
with FreeBSD 7.2 - and none of it works for me.

So far, the only thing I've found that works is to revert the
xorg-server and x11-drivers ports to 2009-Apr-01.  (Though this leaves
me without DRI on my HD2400).

As I stated when the xorg 7.3 debacle was foisted on users: "Maybe the
Xorg sub-project needs to get some input from the Gnome and KDE
sub-projects.  Both these groups manage to upgrade their ports without
regularly breaking everything."  Unfortunately, nothing has been done
and xorg is now worse than ever.

--
Peter Jeremy

[Robert Noland]

On Sat, 2009-05-16 at 09:23 +1000, Peter Jeremy wrote:

> Am I the only person who thinks the X.Org Project has lost its way (or
> at least lost sight of its user community)?  Ever since X.org 6.9,
> successive releases of X.org have provided regressions and POLA
> violations.
>
> Whilst the X.Org Project has been adding native support for newer
> GPUs, it has been doing so at the cost of basic functionality: If you
> happen to be one of the lucky ones who gets the incantations and
> sacrifices right then you might have accelerated 3D on your new
> graphics card.  More likely, it will hang your system if you try to
> use it, or you won't be able to use X at all - even on cards that used
> to work.
>
> The transition from X.org 6.9 to X.org 7.0 added no new functionality.
> It just split X into several hundred pieces and massively increased
> the build time.  The justification was that bugs in one component
> could be corrected by just rebuilding that component.  The reality has
> been that the concepts of regression testing and integration testing
> have gone out the door and new versions of arbitrary components (which
> may or may not be API/ABI compatible with previous versions) are just
> dumped on the user community.
>
> The biggest regression in 7.0 was the switch from imake to GNU
> configure.  Whilst GNU configure is promoted as a portability aid,
> anyone who attempts to port code to (eg) FreeBSD or Solaris will
> quickly discover that the reality is completely the opposite - the
> input language is so arcane it needs two levels of pre-processing by
> custom tools before it can be handled by standard tools and it
> generally provides a long-term, distributed memory for disinformation
> (eg "the native object format for FreeBSD is a.out and objformat can
> be used to check for ELF").  The appallingly bad performance of
> configure (for some X components, configure takes 4-5 times as long to
> run as the actual compilation), combined with the massive increase in
> the number of pieces caused a massive increase in compilation time.
> The FreeBSD performance was further worsened by the (known) poor
> scaling of the packaging tools to large numbers of ports and
> dependencies (stock xorg currently has ~250 build dependencies and
> over 200 run dependencies).
>
> X.org 7.1 was never commited into the ports tree and I don't have
> any record of specific problems with X.org 7.2.
>
> X.org 7.3 introduced another major set of regressions:
> - hard-wired modelines that can't be disabled without patching the
>   source code (though this may be been broken earlier than 7.3).
> - xdm config files installed into the wrong directory
> - Broken files installed into /usr/local/lib/X11/xdm
> - Corrupt xdm/Xresources file installed
> - Display corruption when VTY/X11 switching on an ATI Radeon XPRESS 200M
> - system clock occasionally loses a second during a VTY/X11 switch
> - DPMS display off/on can corrupt display on ATI X200M.
> - Use-after-free error causes Xserver to consistently abort() on exit
> - Keyboard LEDs stopped working
> - Scroll wheel stopped working
> - HW cursor and DPMS broken on MGA G550
> - excessive gettimeofday() calls due to a configure bug
>
> Many of them were subsequently fixed and some were problems in the
> FreeBSD ports rather than the underlying X.org but it is unfortunate
> that the code was committed to the ports tree before being fixed.
>
> Somewhat after X.org 7.3 was committed, having followed the pain felt
> by many others as well as having experienced problems myself, I wrote:
> "Having followed X within FreeBSD from XFree86 3.1.2 through to X.org
> 7.3, I can safely say that X.org 7.3 is by far the worst version as
> far as POLA violations and regressions are concerned."
>
> Well, that was before X.org 7.4 was released - which set a new record
> for brokenness.
>
> So far, X.org 7.x releases have focused on the server.  X.org 7.4 adds
> new client side functionality - with a new "Generic Event Extension".
> Unfortunately, this was done before server support was ready - leading
> to a stream of warnings that can't be suppressed.  (I had a look at the
> code and it is carefully crafted to make suppression almost impossible).
>
> Another new misfeature in X.org 7.4 is the use of dbus/hal.  I have
> yet to find any rationale for using hal in an Xserver - hot-plugging
> both keyboards and mice "just works" in FreeBSD and I've yet to see
> any equipment that allows hot-plugging graphics cards.
>
> Whilst trying to rebuild just parts of X, I've also discovered that
> the dependency checks are wrong - eg, I can uninstall libxcb and all
> its dependencies.  When I then try to build xorg-server, it dies
> inside the graphics/dri configure script reporting that x11-xcb is
> missing.  This shouldn't happen.
>
> There were the usual POLA violations:
> - xdm, xconsole, xload, xlsfonts, xmag (and others) were silently
>   dropped from x11-apps
> - The "DontZap" default was quietly reversed, meaning Ctrl-Alt-BS no
>   longer works by default.
> - Only one graphics card is supported.
>
> But the worst problem is that for many people, including myself, the
> Xserver just doesn't work at all.  For the first time since at least
> FreeBSD 2.x, FreeBSD 7.2 has shipped with an Xserver that won't work
> for a significant number of people (as the mailing lists are beginning
> to reveal).
>
> The most common failure modes I've seen is that the Xserver just
> presents a completely blank screen - and all you can do is kill the
> Xserver.  On occasion, I have managed to make the Xserver crash with
> unresolved symbols (this appears to be the result of incorrect and/or
> inadequate dynamic linkage information in some modules resulting in
> required shared objects not being loaded in some cases).
>
> And this occurs across a variety of hardware - i945, ATI X200M, ATI
> Radeon HD2400, with both FreeBSD 7.2-stable and recent 8-current on
> both i386 and amd64.  I've tried building xorg from scratch both with
> and without HAL.  I've tried installing the Xorg packages that shipped
> with FreeBSD 7.2 - and none of it works for me.
>
> So far, the only thing I've found that works is to revert the
> xorg-server and x11-drivers ports to 2009-Apr-01.  (Though this leaves
> me without DRI on my HD2400).
>
> As I stated when the xorg 7.3 debacle was foisted on users: "Maybe the
> Xorg sub-project needs to get some input from the Gnome and KDE
> sub-projects.  Both these groups manage to upgrade their ports without
> regularly breaking everything."  Unfortunately, nothing has been done
> and xorg is now worse than ever.

You failed to mention that I am essentially the only person maintaining
Xorg, drm, Mesa (libGL, dri, etc...) and at least some subset of agp.
Even with my hardware arsenal having improved dramatically in recent
months, I am only one person...  Some of the issues that you raise are
Xorg in general, while some are porting issues.  Since I don't see
patches attached, I have to assume that you are ok with that.  On the
one hand you want drm/dri support for the HD2400, yet you don't seem to
want any code changes.  Intel is on the brink of just not working at all
if I don't get at least GEM ported.  I can not and will not try to do a
full regression test on every card/driver that exists.  Many drivers for
older hardware are simply unmaintained and it's lucky if they still
compile.  Issues may be addressed with these drivers if they are raised,
but if bugs aren't filed on freedesktop.org, then they just bitrot and
die.

While we do experience some pain, I think that stating that "X just
doesn't work for a significant number of users" is a bit dramatic.  Most
issues that I run across are pilot error and while I agree that work
could be done to help improve that situation either with documentation
or additional work on the ports.  I just simply can't do more than I'm
doing now...

Some of the POLA issues that you raise have been discussed on Xorg lists
and have valid reasons for the changes, for at least some value of
valid.  The change to libpciaccess is what broke multi-card setups, but
would you argue that the xserver should be doing os specific frobbing of
the pci bus?  While this particular issue is being worked on again
lately, the overall number of users that it effects is relatively small.

While FreeBSD does support hot-plugging of mice via moused, it doesn't
support any other types of input devices.  It also doesn't allow for the
individual input devices to have different properties or be managed
independently for different screens or servers.  The same goes for
kbdmux.

robert.

--
Robert Noland <rnoland@...>
FreeBSD

[Peter Jeremy]

On 2009-May-15 19:28:28 -0500, Robert Noland <rnoland@...> wrote:
>> The most common failure modes I've seen is that the Xserver just
>> presents a completely blank screen - and all you can do is kill the
>> Xserver.

It turns out this is another POLA violation, rather than a broken X
server.  It seems that a totally blank/black screen is the new (poorly
documented) standard and you need to use the '-retro' option to get
anything to display by default.

>You failed to mention that I am essentially the only person maintaining
>Xorg, drm, Mesa (libGL, dri, etc...) and at least some subset of agp.

Possibly because I wasn't aware.  Given how important X is to desktop
users, it's unreasonable to expect one person to carry the load
(though, having said that, I can't offer to help because I've already
over-committed my free time to other areas).  I agree that you do an
excellent job.  My mail was written in frustration (and I know I'm not
the only person who is frustrated with Xorg) at making no progress for
more than a month.

>months, I am only one person...  Some of the issues that you raise are
>Xorg in general, while some are porting issues.

The most aggravating issue is the lack of documentation - the commit
to xorg-apps made no mention of the removal of a large number of
clients and neither did UPDATING.  There has been no mention of the
changes in X.org 7.4 (other than dribs and drabs here).  It appears
that the X11 Configuration chapter of the handbook was updated to
cover Xorg 7.4 a couple of weeks ago but that wasn't mentioned here
until today.

>  Since I don't see
>patches attached, I have to assume that you are ok with that.

I have previously provided patches to correct an Xserver bug (the PR
is still open) and will continue to provide patches as I get time.  I
have also tested patches supplied by others where relevant and have
previously requested that you circulate patchsets for testing major
Xorg upgrades before committing them.  I am happy to run experimental
code and find/fix bugs when I know it's experimental.  I'm not happy
when I run what is supposed to be production code and it doesn't work
as expected for no obvious reason.  Unfortunately, my free time is
limited and having wasted at least a week tracking down the latest
POLA violation means I have lost a week of work that I could have used
to write patches on Xorg or other projects I am trying to work on.

>  On the
>one hand you want drm/dri support for the HD2400, yet you don't seem to
>want any code changes.

I am not saying that.  I am saying that the Xorg project needs to stop
breaking existing functionality and unnecessarily changing existing
behaviour.  Things like inverting the sense of "DontZap" or making the
default screen blank with no cursor have no benefit and just waste
people's time.

>  Intel is on the brink of just not working at all
>if I don't get at least GEM ported.

I've seen references to GEM (and messages about it not existing) but
don't know anything about it.  What is it and what is involved in
porting it?

>  I can not and will not try to do a
>full regression test on every card/driver that exists.

I'm not expecting you to do this.  It would be nice if the Xorg
project did some regression testing though

>  Many drivers for
>older hardware are simply unmaintained and it's lucky if they still
>compile.

I've not even tried using Xorg 7.4 on "older hardware" yet - my concern
is that Xorg appear to be unnecessarily changing things (and this will
obviously increase the risk of bitrot).

>While we do experience some pain, I think that stating that "X just
>doesn't work for a significant number of users" is a bit dramatic.  Most
>issues that I run across are pilot error

It seems that Xorg 7.4 has made a number of radical changes to a large
number of different areas - resulting in configuration options
interacting in ways that are people aren't expecting.  Whilst it could
be called "pilot error", the lack of documentation doesn't help.  I
know I reported "blank screen on startup" and asked for help a month
ago - whilst you did respond, you didn't actually mention that this
was now the expected behaviour.

> and while I agree that work
>could be done to help improve that situation either with documentation

I am not blaming you.  XFree86 was fairly well documented.
Unfortunately, most of the Xorg documentation was inherited from
XFree86 and doesn't seem to have been touched since.  An excellent
example is the Xorg 7.4 page - http://www.x.org/wiki/Releases/7.4 -
it contains a link to 'ChangeLog' but the target page doesn't exist.
It talks about per-module changelogs but provides no indication as
to how to find them.

>  The change to libpciaccess is what broke multi-card setups, but
>would you argue that the xserver should be doing os specific frobbing of
>the pci bus?

This is a classic example of an unnecessary regression - the existing
code worked but was replaced with new code that isn't ready yet.  I
agree that libpciaccess appears to be the way to go but it shouldn't
be the default in a 'stable'/'production' release of Xorg until it
provides at least equivalent functionality.

>While FreeBSD does support hot-plugging of mice via moused, it doesn't
>support any other types of input devices.

Actually, hot-plugging keyboards _is_ supported and works according
to some testing last night.

>  It also doesn't allow for the
>individual input devices to have different properties or be managed
>independently for different screens or servers.

Well, due to the libpciaccess bungle, you can't have multiple servers
any longer so that just leaves different screens.  And I would suggest
that the number of people who use input devices other than mouse or
keyboard (note that these are the only devices installed by the xorg
meta-port) and/or want them to have different properties for different
screens is vanishingly small.

--
Peter Jeremy

[Adam K Kirchhoff]

On Sat, 16 May 2009 21:09:38 +1000
Peter Jeremy <peterjeremy@...> wrote:

<snip>

> I am not saying that.  I am saying that the Xorg project needs to stop
> breaking existing functionality and unnecessarily changing existing
> behaviour.  Things like inverting the sense of "DontZap" or making the
> default screen blank with no cursor have no benefit and just waste
> people's time.

That hs been discussed a number of times on various mailing lists and
forums.  You should really politely take up that decision up with the
Xorg folks.  Complaining on here isn't going to do any good (though,
very likely, complaining on the Xorg mailing list won't either, but at
least that's a more applicable place).

<snip>
> I'm not expecting you to do this.  It would be nice if the Xorg
> project did some regression testing though

They do.  Probably much more than you realize.  Bear in mind one
important thing, though...  For the most part, they are all using
Linux, not FreeBSD.  They either use Linux because they want to or, for
quite a few developers, because hardware vendors pay them to.  AMD and
Intel pay open source developers to write Linux drivers and to improve
the Xorg stack for their linux users.  Thankfully we have someone like
Robert who is working so hard on trying to maintain a level playing
field.

Adam
_______________________________________________
freebsd-x11@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@..."

[James Mansion-2]

Robert Noland wrote:
> Xorg in general, while some are porting issues.  Since I don't see
> patches attached, I have to assume that you are ok with that.  On the
>  
I thought in general people had grown out of 'send me the patches' but
clearly not.  Is it
not OK to be just a user, and to complain when the system regresses?

> Some of the POLA issues that you raise have been discussed on Xorg lists
> and have valid reasons for the changes, for at least some value of
> valid.  The change to libpciaccess is what broke multi-card setups, but
> would you argue that the xserver should be doing os specific frobbing of
> the pci bus?  While this particular issue is being worked on again
> lately, the overall number of users that it effects is relatively small.
>
>  
 From the point of view of a dispassionate observer, it does seem that
X.org has moved slowly
but significantly from an attempt to keep all its user communities happy
to focussing greatly
on Linux and caring little if *BSD and *Solaris lack the resources to
keep up trying to emulate
design decisions that are Linux-centric, then that's just tough.  Or so
it seems.

I don't think anyone can blame you for being a bit defensive Robert.  
The problem is
with X.org.  Upstream need to be honest with everyone about how much
they care about
some of their users.

Maybe we will all come to regret that no-one seemed interested in taking
the old Scitech
SNAP product further when they gave up on it.

(http://www.scitechsoft.com/news/press/sale_of_snap.html)


Perhaps the answer is to step back and consider whether something akin
to the emulation
that allows Windows NDIS drivers to run could be fashioned to allow
Windows graphics
drivers to run - perhaps using recent virtualisation advances to limit
the damage they can
do.  While politically painful on some levels, it does provide for a
functional binary
compatibility abstraction.  Pretty soon most of us will have desktop
devices that handle the
new x86 virtualization features and it becomes increasingly pointless to
hang onto old
X terms when you can get hardware like an Aspire Revo for peanuts.

I've not looked at building X recently, but if the new build system is
so bad, then why
not replace it?  waf seems handy to me.  Its a lot faster than scons,
handy to script in
Python, and can handle configuration tasks etc.

James

_______________________________________________
freebsd-x11@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@..."

[Romain Tartière-2]

Hi

On Sat, May 16, 2009 at 09:09:38PM +1000, Peter Jeremy wrote:
> On 2009-May-15 19:28:28 -0500, Robert Noland <rnoland@...> wrote:
> > Intel is on the brink of just not working at all if I don't get at
> > least GEM ported.
>
> I've seen references to GEM (and messages about it not existing) but
> don't know anything about it.  What is it and what is involved in
> porting it?

I read this article just a few days ago:
http://www.freesoftwaremagazine.com/columns/the_new_xorg_features
It gives general information about GEM (I did not know anything about it
before).

Some pointers are also available on wikipedia:
http://en.wikipedia.org/wiki/Graphics_Execution_Manager

This may help you to figure out what is GEM.  For your second questions
however, I have no answer to provide.

Regards,
Romain

--
Romain Tartière <romain@...>        http://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)

[Jan Henrik Sylvester]

Peter Jeremy wrote:
> On 2009-May-15 19:28:28 -0500, Robert Noland <rnoland at FreeBSD.org> wrote:
>>While FreeBSD does support hot-plugging of mice via moused, it doesn't
>>support any other types of input devices.
>
> Actually, hot-plugging keyboards _is_ supported and works according
> to some testing last night.

There are other common input devices than keyboards and plain mice. I
guess I am not the only laptop user with a Synaptics Touchpad that has
so much more functionality with the xorg driver than with the one of
FreeBSD. At the same time I would like to be able to attach and remove
my usb mouse at any time.

The way the configuration has to be setup for this to work changed a
couple of times from xorg 6.9 to the current version -- it was sometimes
pretty hard to get the information. Anyhow, considering how difficult
such a common setup was (and still is) to make work, I think xorg is
going in the right direction overall. (I have not been able to change
from the classic configuration with the devices configured in xorg.conf
to the new order in a way that is satisfying, but that is not the point.)

Yes, xorg gave me some pain, but just now I am very satisfied: My intel
945GME based Eee PC can switch VTY/X11 for the very first time without
the screen blanking after the upgrade to 7.2-RELEASE (thanks so much for
the DRM updates!) and does not crash anymore on playing video after the
latest driver update -- which happened independently of an server
release. My rather old radeon r200 based laptop does 2D and 3D with less
problems than ever before. Another nvidia based laptop works fine with
the closed driver -- I hope an open one will replace it one day, but it
works with composite and 3D at the same time now.

Some less xorg related breakage would be nice, but xorg makes progress
that is obviously needed for new cards to be supported with good 2D and
3D and at the same time eliminating the archaic xorg.conf that is a pain
for multiple input devices, multiple screens, and so on. Each time this
progress hits me, I swear, too, but overall it seems to be necessary.

Robert does incredible work porting all this to FreeBSD following all
Intel, ATI, and Nvidia with their obviously very different development
styles.

Cheers,
Jan Henrik
_______________________________________________
freebsd-x11@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@..."

[Boris Samorodov]

On Sat, 16 May 2009 14:32:33 +0200 Jan Henrik Sylvester wrote:

> Yes, xorg gave me some pain, but just now I am very satisfied: My
> intel 945GME based Eee PC can switch VTY/X11 for the very first time
> without the screen blanking after the upgrade to 7.2-RELEASE (thanks
> so much for the DRM updates!) and does not crash anymore on playing
> video after the latest driver update -- which happened independently
> of an server release. My rather old radeon r200 based laptop does 2D
> and 3D with less problems than ever before.

For me 7.4 was the first release which gave me a possibility to
use my ATI r300 card -- I could use it only at vesa modes.

And big thanks to Robert too!


WBR
--
Boris Samorodov (bsam)
Research Engineer, http://www.ipt.ru Telephone & Internet SP
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
_______________________________________________
freebsd-x11@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@..."

[Jimmie James]

ON Fri, 15 May 2009 19:28:28 -0500
Robert Noland said:

>You failed to mention that I am essentially the only person maintaining
>Xorg, drm, Mesa (libGL, dri, etc...) and at least some subset of agp.

I for one, thank you for all of your hard work, time and dedication. For
one person to handle such a mess is, impressive, to say the least.
I personally feel there's not enough thanks and praise for all your work.

>Intel is on the brink of just not working at all if I don't get at least GEM ported.

I'm very sad to hear this, as for now I'm stuck with a
vgapci0@pci0:0:2:0:     class=0x030000 card=0x25821043 chip=0x25828086
rev=0x04 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = '82915G/GV/GL, 82910GL Integrated Graphics Device'
I also have a box with an i810 in it.

I can't code/port to save a drowning kitten's life, but if you need a
tester, I'd be willing, as long as rolling back to the "working" Xorg is
possible, and there's no damage done to the hardware, though I may need
a bit of handholding.

Robert, feel free to contact me on/off-list (not subscribed, but read
daily) if there's anything I can do to help.


Thank again for all your work.
--
Over the years I've come to regard you as people I've met.

_______________________________________________
freebsd-x11@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@..."

[Robert Noland]

On Sat, 2009-05-16 at 21:09 +1000, Peter Jeremy wrote:
> >  Intel is on the brink of just not working at all
> >if I don't get at least GEM ported.
>
> I've seen references to GEM (and messages about it not existing) but
> don't know anything about it.  What is it and what is involved in
> porting it?

GEM is one of two kernel memory managers.  The other is TTM which was
the first attempt.  TTM is also now being redeveloped based on the
experience gained from the first attempt.  GEM is Intel's solution and
the 2.7.x series driver will be the last driver to work without
UXA/DRI2/GEM and possibly KMS (Kernel Mode Setting).  The radeon and
nouveau drivers are expected to use a TTM backend while providing a GEM
API to userland.  Last I heard, the openchrome driver will be TTM, but
I'm not as tuned in to that development as I still don't have via
hardware.

robert.

--
Robert Noland <rnoland@...>
FreeBSD

[Robert Noland]

On Sat, 2009-05-16 at 12:31 +0100, James Mansion wrote:
> Robert Noland wrote:
> > Xorg in general, while some are porting issues.  Since I don't see
> > patches attached, I have to assume that you are ok with that.  On the
> >  
> I thought in general people had grown out of 'send me the patches' but
> clearly not.  Is it
> not OK to be just a user, and to complain when the system regresses?

Yes, it is fine to be just a user and I try to address any issues
brought to my attention.  I am just overloaded and at the very least
need good debugging info.  In general, I just need other folks to take
an interest in helping with X and all the bits and pieces that go along
with it.  Whether that is trying to help with documentation or porting
or just trying to help answer other users questions when you can.

> > Some of the POLA issues that you raise have been discussed on Xorg lists
> > and have valid reasons for the changes, for at least some value of
> > valid.  The change to libpciaccess is what broke multi-card setups, but
> > would you argue that the xserver should be doing os specific frobbing of
> > the pci bus?  While this particular issue is being worked on again
> > lately, the overall number of users that it effects is relatively small.
> >
> >  
>  From the point of view of a dispassionate observer, it does seem that
> X.org has moved slowly
> but significantly from an attempt to keep all its user communities happy
> to focussing greatly
> on Linux and caring little if *BSD and *Solaris lack the resources to
> keep up trying to emulate
> design decisions that are Linux-centric, then that's just tough.  Or so
> it seems.

Well, Intel is trying to drive a lot of development and are only focused
on linux.  While they aren't actively trying impede our progress, they
aren't really concerned with providing us much help.  Other driver
developers are more kind in general, AMD has been really good to work
with both from the aspect of providing me with hardware and trying to
produce code that doesn't require massive changes to work on FreeBSD or
linux.  The Nouveau developers are also quite happy to work with us.
Almost all development is done on linux though.

> I don't think anyone can blame you for being a bit defensive Robert.  
> The problem is
> with X.org.  Upstream need to be honest with everyone about how much
> they care about
> some of their users.

> Maybe we will all come to regret that no-one seemed interested in taking
> the old Scitech
> SNAP product further when they gave up on it.
>
> (http://www.scitechsoft.com/news/press/sale_of_snap.html)
>
>
> Perhaps the answer is to step back and consider whether something akin
> to the emulation
> that allows Windows NDIS drivers to run could be fashioned to allow
> Windows graphics
> drivers to run - perhaps using recent virtualisation advances to limit
> the damage they can
> do.  While politically painful on some levels, it does provide for a
> functional binary
> compatibility abstraction.  Pretty soon most of us will have desktop
> devices that handle the
> new x86 virtualization features and it becomes increasingly pointless to
> hang onto old
> X terms when you can get hardware like an Aspire Revo for peanuts.

I really don't think that is is at all feasible... At least not if you
expect any sort of performance.

> I've not looked at building X recently, but if the new build system is
> so bad, then why
> not replace it?  waf seems handy to me.  Its a lot faster than scons,
> handy to script in
> Python, and can handle configuration tasks etc.

Well, I really don't have a big problem with the build system.  Sure
maybe it could be more efficient or faster, but even I don't build
everything that often and building X is pretty fast, when compared to
building gnome or kde.

robert.

> James
>
--
Robert Noland <rnoland@...>
FreeBSD

[Robert Noland]

On Sat, 2009-05-16 at 10:25 -0400, Jimmie James wrote:

> ON Fri, 15 May 2009 19:28:28 -0500
> Robert Noland said:
>
> >You failed to mention that I am essentially the only person maintaining
> >Xorg, drm, Mesa (libGL, dri, etc...) and at least some subset of agp.
>
> I for one, thank you for all of your hard work, time and dedication. For
> one person to handle such a mess is, impressive, to say the least.
> I personally feel there's not enough thanks and praise for all your work.
>
> >Intel is on the brink of just not working at all if I don't get at least GEM ported.
>
> I'm very sad to hear this, as for now I'm stuck with a
> vgapci0@pci0:0:2:0:     class=0x030000 card=0x25821043 chip=0x25828086
> rev=0x04 hdr=0x00
>      vendor     = 'Intel Corporation'
>      device     = '82915G/GV/GL, 82910GL Integrated Graphics Device'
> I also have a box with an i810 in it.

Ok, perhaps I over-stated just a bit... The 2.7 series driver an beyond
*should* work with UXA and no drm.

robert.

> I can't code/port to save a drowning kitten's life, but if you need a
> tester, I'd be willing, as long as rolling back to the "working" Xorg is
> possible, and there's no damage done to the hardware, though I may need
> a bit of handholding.
>
> Robert, feel free to contact me on/off-list (not subscribed, but read
> daily) if there's anything I can do to help.

Thanks, One of my biggest issues right now is being so overwhelmed that
I'm only occasionally able to focus on a single aspect.

robert.

>
> Thank again for all your work.
--
Robert Noland <rnoland@...>
FreeBSD

[Peter Jeremy-2]

On 2009-May-16 07:30:16 -0400, Adam K Kirchhoff <adamk@...> wrote:

>On Sat, 16 May 2009 21:09:38 +1000
>Peter Jeremy <peterjeremy@...> wrote:
>> I am not saying that.  I am saying that the Xorg project needs to stop
>> breaking existing functionality and unnecessarily changing existing
>> behaviour.  Things like inverting the sense of "DontZap" or making the
>> default screen blank with no cursor have no benefit and just waste
>> people's time.
>
>That hs been discussed a number of times on various mailing lists and
>forums.

But, AFAIR, not on any relevant FreeBSD lists.  As someone who wants
to _use_ X11 on FreeBSD, I should not need to follow the Xorg mailing
lists to learn about what has been broken in the latest release.
There are limits to how many different mailing lists I can follow...

>> project did some regression testing though
>
>They do.  Probably much more than you realize.

As an Xorg user, all I can say is that it doesn't show.  As I have
previously said, the sort of basic problems that are showing up with
X.org 7.3 and 7.4 were not apparent with XFree86 or Xorg 6.x.

--
Peter Jeremy

[William Cheswick]

Robert,

I salute you in your lonely attempts to keep up with the bloat from Xorg. Your efforts deserve more support than that: FreeBSD is too important.

Alas, I fear that these problems are threatening the choice to use FreeBSD as an OS for clients.  I am spending more and more time dealing with the kinds of problems others have listed here.  Unfortunately, there really are no good alternatives: Linux has bloat of its own, and isn't quite Unix, Apple is a possibility, at least with enough support.

Bill Cheswick

[Curtis Villamizar-2]

In message <24153871.post@...>
William Cheswick writes:

>  
>  
> Robert,
>  
> I salute you in your lonely attempts to keep up with the bloat from Xorg.
> Your efforts deserve more support than that: FreeBSD is too important.
>  
> Alas, I fear that these problems are threatening the choice to use FreeBSD
> as an OS for clients.  I am spending more and more time dealing with the
> kinds of problems others have listed here.  Unfortunately, there really are
> no good alternatives: Linux has bloat of its own, and isn't quite Unix,
> Apple is a possibility, at least with enough support.
>  
> Bill Cheswick

It might help to have CVS tags in the ports collection such as the
base OS RELENG tags, at least in the x11-* ports.  Either that or use
the cvsup date= feature and fetch x11 ports that way.

Curtis
_______________________________________________
freebsd-x11@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-x11
To unsubscribe, send any mail to "freebsd-x11-unsubscribe@..."