peterjeremy at optushome.com.au
Sat May 16 11:09:42 UTC 2009
On 2009-May-15 19:28:28 -0500, Robert Noland <rnoland at FreeBSD.org> 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
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
> 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
> 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
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20090516/cbe72a50/attachment.pgp
More information about the freebsd-x11