On Sun, Sep 26, 2010 at 10:04 PM, DJ Lucas <d...@linuxfromscratch.org> wrote:
> On 09/26/2010 03:23 PM, Dan Nicholson wrote:
>> On Sat, Sep 25, 2010 at 10:06 PM, DJ Lucas <d...@linuxfromscratch.org> wrote:
>>> On 09/23/2010 06:33 PM, Ken Moffat wrote:
>>>
>>>> With my essentially-LFS-6.7 desktop I'm noticing that if I have
>>>> firefox open on one desktop, and something else in the same area on
>>>> another, when I go back to firefox it takes a noticeable time to
>>>> repaint itself, even if the processor was idle. This is with
>>>> xorg-server-1.9. Compare to the 1.7-series servers where I only
>>>> notice delays if I'm compiling something.
>>>>
>>>> So, I looked at the thread that was pointed to. I got quite
>>>> confused by all the references to fglrx, but eventually picked the
>>>> xserver-xorg-backclear.patch from Felix Kuehling [attached]. Was
>>>> that what you were talking about ?
>>>
>>> Yes. IIUC, the patch that was added upstream creates about a 300ms
>>> delay on resize of all windows on all devices because it reads back from
>>> VRAM to get a bitmap to fill the area before the resize. This is has a
>>> very bad effect on fglrx drivers, but the same delay applies equally to
>>> all devices. The delay was what made the light bulb go on before. This
>>> applies to the 1.7 server as well, so this is definitely something
>>> different WRT 1.9.
>>>
>>> As far as xorg-server in the book, I'm sticking with 1.7.7 for now with
>>> an R7.5-3 release which I plan to introduce tonight or tomorrow as it
>>> has been tested thoroughly. Unless somebody has a very compelling
>>> reason to upgrade to xorg 7.6-pre, I'm not planning on putting 1.8.x
>>> into the book at all as this was the version series slotted for R7.6.
>>> It does look like 1.9 is slotted for R7.6 now according to
>>> http://www.x.org/wiki/Releases/7.6 . I was under the impression that
>>> 1.8.x never finished the new input hotplugging code and they were
>>> scrapping it for R7.6 (but that info is well over a year old now but
>>> still seems current according to the above page).
>>
>> No, the input hotplugging has been in for quite some time. A really
>> good reason to upgrade to 1.9 is that a udev backend has been added.
>> So, you don't need HAL to get hotplugged goodness.
>
> Dan, thanks for piping in on that. I appreciate it. Actually, I was
> referring to XKB2 (and XI3) above, not hotplugging. I've been out of it
> for a while and was just confused about the mix of upcoming features.
Yeah, XKB2 is the long awaited XKB rewrite (the code is terrible), but
it really has very little effect on users. One nice one will be
killing xkbcomp, which the server currently forks almost every time an
input device is added. Mostly it's about cleaning up cruft in the API,
but the user will still be configuring devices through Rules, Model,
Layout, Variant and Options.
I'm not exactly sure what XI3 refers to, but I think it's Peter
Hutterer's work to clean up the input driver API, which had grown in
many directions over the years. This should have no effect on users so
long as any input drivers you care about are ported to the new API
(they should be).
> So with xorg-server-1.8.0 (and 1.9.0), HAL (and old PolicyKit-0.9) can
> be dropped from the book? I think it is time to start testing, but that
> means no Xorg update in the book for a while. I was thinking that I
> might just go ahead and do a 7.5 update anyway since I know it is stable
> and I've just about got it ready to go as that would leave something
> fairly recent until an official 7.6 is upon us, which was supposed to
> occur next month anyway. However, beyond the 7.5-3, the 7.6 update will
> basically be updated server and a handful of client libs and apps, and
> nearly a complete rewrite of the configuration section. Gotta come up
> with something for /etc/X11/xorg.conf.d/ (this will be minimal as I
> don't even use an xorg.conf any longer as things just work out of the
> box) and some sample udev rules (though I don't fully understand the
> interaction yet).
Yes, killing HAL was a big motivation for that feature, but there's
still some packages here and there that require HAL. You should be
able to run the server with no additional configuration in
xorg.conf/xorg.conf.d. The server installs one .conf file in
$datadir/X11/xorg.conf.d so that all input devices will fall back to
using evdev, and the hardware specific drivers (like synaptics and
wacom) should install their own .conf files so they take precedence
for the devices they match.
The udev rules can really only be used for controlling XKB options
because distros had a method of populating a rules file at boot from
system default keyboard options. I'd skip them completely if you don't
have a similar method. If you're using input hotplugging, this is all
you'd need to set default XKB settings is a simple class definition:
cat > /etc/X11/xorg.conf.d/xkb-defaults.conf << "EOF"
Section "InputClass"
Identifier "XKB Defaults"
MatchIsKeyboard "yes"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EOF
You can also specify you're default XKB settings at build time,
although I can't remember the right --with-* options at the moment.
> What else has gone? Is server-1.9.0 stable with the rest of the current
> client software? Nothing needed from git to use all features of the new
> server? If so, I should actually just scrap my existing plans, ditch the
> Xorg official "Release" cycle and just do a mix and match, and call it
> just Xorg (no release number). Seems that the distributions have been
> doing individual releases anyway, BLFS excluded. Good time to scrap
> bitmap fonts and go with a full TTF/OTF setup.
A lot of cleanup in the last couple server cycles, but not a lot of
new features that I can think of. Removal of a lot of crufty
extensions that you'll never know were gone. If you can be a little
patient, Xorg-7.6 is being put together with xorg-server-1.9.x as the
centerpiece. I forget the timeline, but it's happening soon. Here's
Alan's initial module set:
http://lists.x.org/archives/xorg-devel/2010-September/013258.html
But yeah, the distros certainly roll along at their own pace. I'd
personally like to get the katamaris released more often (stable point
releases between the big releases), but that would take some time and
motivation that I don't have too much extra of these days.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
