Xorg Mailing List 2004 July

From loc at toya.net.
pl Thu Jul 1 04:19:02 2004

From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Thu Jul 1 04:19:12 2004
Subject: [Xorg] sed errors with --enable-xorgserver
In-Reply-To: <1088660842.9818b11cplazmatikz_nz@myrealbox.com>
References: <1088660842.9818b11cplazmatikz_nz@myrealbox.com>
Message-ID: <40E3F326.80105@toya.net.pl>
Mike Russell wrote:
> Hi i am trying to build xserver but
> whenever i give it --enable-xorgserver It generates these errors during
> configure and makes blank makefiles.
sed -ie 's/ac_max_sed_lines=[0-9]*/ac_max_sed_lines=100/' configure
and rerun ./configure (*not* autogen.sh).
btw. AFAIR xorg in the xserver tree is broken.
--
Regards,
Jakub Piotr C?apa
From krh at bitplanet.net Thu Jul 1 04:25:23 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Thu Jul 1 04:28:44 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <Pine.LNX.4.56.0406291323330.1813@typhoon-04.cs.huji.ac.il>
References: <40D9BFAE.8060801@bitplanet.net> <40DB03EC.8080503@niehs.nih.gov>
<40DC2D3E.40209@bitplanet.net>
<Pine.LNX.4.56.0406281101040.12734@grok.cs.huji.ac.il>
<40E1426B.9090604@bitplanet.net>
<Pine.LNX.4.56.0406291323330.1813@typhoon-04.cs.huji.ac.il>
Message-ID: <40E3F4A3.9000500@bitplanet.net>
Ely Levy wrote:
> On Tue, 29 Jun 2004, [UTF-8] Kristian H?gsberg wrote:
>
>
>>Ely Levy wrote:
>>
>>>Hey,
>>>just few points from when I looked ar xinput
>>>1)It would be nice to have user configurable options
>>>2)Mouse wheel should be mapped to zaxis and not buttons 4,5
>>
>>Well, it really should be a vertical wheel event, I think. Mapping it to
>>z-axis is also "wrong".
>
>
> You mean a special event for it?
> what's the diffrent between that and zaxis?
> or do you want to add zaxis and then be able to map it to diffrent events
> which one of them can be the vertical wheel?
> I think there are already mouse/joystick which support horizontal wheel
> btw I don't see the day where people would use joystick for x that far
> away:)
The z-axis is the third dimension, ie you would use it for the z
coordinates if you had a three dimensional pointer device. If you want
to change wheel events away from button 4 and 5, I think it would make
sense to define new events for wheel up and wheel down. If you look at
the Linux kernel input layer, it's how they do it. They also have
events for horizontal wheels. Some Microsoft mice and keyboards have
wheels that can tilt left/right to generate these events.
Kristian
Date: Thu Jul 1 05:45:05 2004
In-Reply-To: <20040629184439.85565.qmail@web14928.mail.yahoo.com>
References: <20040629184439.85565.qmail@web14928.mail.yahoo.com>
Message-ID: <40E406FC.8060205@bitplanet.net>
Jon Smirl wrote:
> --- Kristian H?gsberg <krh@bitplanet.net> wrote:
>
>>>While currently it is not possible to run multiple X servers on the
>>>same system (multi seat) it might well be in the future. In this
>>>case it must be made sure that only one of these servers connects
>>
>>to
>>
>>>the device and that after a replug the same server gets the device
>>>reassigned.
>>
>>Yeah, that's a good point. The discovery mechanism should remember
>>which server to add the device to.
>
>
> This needs to be part of a bigger design, probably using udev. fbdev
> has the same problem and we don't want to build two parallel systems
> for assigning devices.
>
> One solution would be to tag device with a console id in udev.conf --
> console 0, 1, 2, etc and assign each xserver a console id too. The
> hotplug program could then match the device to the correct xserver.
> Instead of making up console ids you could use the dri device number.
Sure, if you have a machine with multiple physical terminals, you
probably already have configured groups of mouse+keyboard+video. The X
server should respect that and only pick up the devices from that group.
This only works if you have configured this ahead of time, if you
plug in a brand new device, what's the right thing to do?
Kristian
From brian.paul at tungstengraphics.com Thu Jul 1 06:46:38 2004
From: brian.paul at tungstengraphics.com (Brian Paul)
Date: Thu Jul 1 06:52:57 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: <20040701032446.GU21053@fooishbar.org>
References: <40E186BE.89043BC7@nrubsig.org>
<20040629151608.GB21053@fooishbar.org>
<40E2D2B5.9020709@tungstengraphics.com>
<20040701032446.GU21053@fooishbar.org>
Message-ID: <40E415BE.7070909@tungstengraphics.com>
Daniel Stone wrote:
> On Wed, Jun 30, 2004 at 08:48:21AM -0600, Brian Paul wrote:
>
>>Daniel Stone wrote:
>>
>>>Convert the loginfo file to use new-style format strings, instead of
>>>%{sVv}. I don't know what the new-style format strings are. All I know
>>>%is that, yes, it's annoying as hell.
>>
>>Would somebody please update the mesa/CVSROOT/loginfo file for me? I
>>don't seem to have permission.
>
>
> Of course you do - loginfo,v is 775. You don't edit the file directly,
> you do cvs co CVSROOT from :ext:cvs.freedesktop.org:/cvs/mesa. You edit
> loginfo there, and check it in. You'll also need to update checkoutlist.
I've tried various things, but always get errors like this:
Enter passphrase for key '/home/brian/.ssh/id_rsa':
cvs checkout: Updating CVSROOT
cvs checkout: failed to create lock directory for `/cvs/mesa/CVSROOT'
(/cvs/mesa/CVSROOT/#cvs.lock): Permission denied
cvs checkout: failed to obtain dir lock in repository `/cvs/mesa/CVSROOT'
cvs [checkout aborted]: read lock failed - giving up
Is that a stale CVS lock?
>>I think that whoever updated the CVS software should have updated the
>>scripts too.
>
>
> I updated cvs, to 1:1.12.9-1.1. Before that, it was myself who updated to
> 1:1.12.8-1.1, and 1:1.12.3-1.1. These were all security releases, and
> there's something like eight compromises fixed.
>
> I have no desire to maintain a forked copy of CVS (with old-style info
> parsing) - having to apply a patch to shut pserver up on read-only mode
> so clients don't get confused is bad enough.
>
> I applied it to fix security issues; I do not know how to update the
> info scripts (I know *how* to do so, but I don't know what to change it
> to). Thus, I have no intention of doing so.
>
> There are 324 repositories across 55 projects. My time spent on admin
> stuff is already stretched beyond what I'd hope it would be; there's no
> way I'm going through and updating all the CVS trees.
>
> I know it sucks, and when I found out, I wanted to punch the physical
> representation of CVS in the head. There's a reason I use tla for most
> everything these days.
Thanks for the info. I had no idea who was changing the CVS software
or why.
-Brian
From daniel at freedesktop.org Thu Jul 1 08:35:15 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Thu Jul 1 08:35:17 2004
In-Reply-To: <40E415BE.7070909@tungstengraphics.com>
<20040629151608.GB21053@fooishbar.org>
<20040701032446.GU21053@fooishbar.org>
<40E415BE.7070909@tungstengraphics.com>
Message-ID: <20040701153515.GA1086@fooishbar.org>
n Thu, Jul 01, 2004 at 07:46:38AM -0600, Brian Paul wrote:
> Daniel Stone wrote:
> >Of course you do - loginfo,v is 775. You don't edit the file directly,
> >you do cvs co CVSROOT from :ext:cvs.freedesktop.org:/cvs/mesa. You edit
> >loginfo there, and check it in. You'll also need to update checkoutlist.
>
> I've tried various things, but always get errors like this:
>
> Enter passphrase for key '/home/brian/.ssh/id_rsa':
> cvs checkout: Updating CVSROOT
> cvs checkout: failed to create lock directory for `/cvs/mesa/CVSROOT'
> (/cvs/mesa/CVSROOT/#cvs.lock): Permission denied
> cvs checkout: failed to obtain dir lock in repository `/cvs/mesa/CVSROOT'
> cvs [checkout aborted]: read lock failed - giving up
>
>
> Is that a stale CVS lock?
Fixed.
> Thanks for the info. I had no idea who was changing the CVS software
> or why.
There's a security update every other day. :\
--
Daniel Stone <daniel@freedesktop.org>
freedesktop.org: powering your desktop http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/bba6d023/attach
ment-0001.pgp
Date: Thu Jul 1 08:37:23 2004
Subject: [Xorg] sed errors with --enable-xorgserver
In-Reply-To: <1088660842.9818b11cplazmatikz_nz@myrealbox.com>
References: <1088660842.9818b11cplazmatikz_nz@myrealbox.com>
Message-ID: <20040701153722.GC1086@fooishbar.org>
On Thu, Jul 01, 2004 at 05:47:22AM +0000, Mike Russell wrote:
> Hi i am trying to build xserver but
> whenever i give it --enable-xorgserver It generates these errors during
> configure and makes blank makefiles.
--enable-xorgserver is deprecated; build the debrix, debrix-input-mouse,
debrix-input-keyboard, and one of debrix-driver-ati or debrix-driver-nv
instead.
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/dae550e2/attach
ment.pgp
From brian.paul at tungstengraphics.com Thu Jul 1 10:40:12 2004
Date: Thu Jul 1 10:46:07 2004
In-Reply-To: <20040701153515.GA1086@fooishbar.org>
<20040629151608.GB21053@fooishbar.org>
<20040701032446.GU21053@fooishbar.org>
<20040701153515.GA1086@fooishbar.org>
Message-ID: <40E44C7C.9050308@tungstengraphics.com>
Well, I've been tinkering with the CVS admin files but can't get
things to work quite right.
I got rid of the message: "Appending defaults (" %r/%p %s"), but
please be aware that this usage is deprecated." by adding the %r/%p %s
parameters in the commitinfo file."
Next, I tried to fix the warning: "cvs commit: Using deprecated info
format strings. Convert your scripts to use the new argument format
and remove '1's from your info file format strings."
I added UseNewInfoFmtStrings=yes to the config file.
In loginfo, it looks like the %s was causing trouble. If I remove it
entirely or use %{s} or %s then no commit message is sent to the
mailer. The only way I can get the mail message to go out is if I use
%1s. But then I get the warning: "cvs commit: Using deprecated info
format strings. Convert your scripts to use the new argument format
and remove '1's from your info file format strings."
Any ideas?
Daniel Stone wrote:
>>>Of course you do - loginfo,v is 775. You don't edit the file directly,
>>>you do cvs co CVSROOT from :ext:cvs.freedesktop.org:/cvs/mesa. You edit
>>>loginfo there, and check it in. You'll also need to update checkoutlist.
In what way do I have to update checkoutlist?
-Brian
Date: Thu Jul 1 10:53:06 2004
In-Reply-To: <40E44C7C.9050308@tungstengraphics.com>
<20040629151608.GB21053@fooishbar.org>
<20040701032446.GU21053@fooishbar.org>
<20040701153515.GA1086@fooishbar.org>
<40E44C7C.9050308@tungstengraphics.com>
On Thu, Jul 01, 2004 at 11:40:12AM -0600, Brian Paul wrote:
> [...]
>
> Any ideas?
I avoid CVS entirely, so no, sorry.
> >>>Of course you do - loginfo,v is 775. You don't edit the file directly,
> >>>you do cvs co CVSROOT from :ext:cvs.freedesktop.org:/cvs/mesa. You edit
> >>>loginfo there, and check it in. You'll also need to update checkoutlist.
>
> In what way do I have to update checkoutlist?
Make sure loginfo is in it. Basically, it maintains a list of files that
it needs to check out from their ,v (i.e. CVS-controlled) equivalents,
rather than just using the versions in there. Putting them in
checkoutlist ensures they get updated automatically.
AIUI, anyway.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/c5397cd3/attach
ment.pgp
From eich at pdx.freedesktop.org Fri Jul 2 06:25:11 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Fri Jul 2 06:26:58 2004
In-Reply-To: krh@bitplanet.net wrote on Tuesday,
29 June 2004 at 13:36:53 +0200
References: <40D9BFAE.8060801@bitplanet.net>
<16607.59124.921806.956671@hermes.local>
<40E15455.9060104@bitplanet.net>
Message-ID: <16613.25143.44541.395195@xf11.fra.suse.de>
Kristian H?gsberg writes:
[...]
> > No, adding this to an extension would only make sense if a functionality
> > is to be network transparent. This doesn't seem to be the case for input
> > devices. Input devices pysically live on the machine the server exists
> > on. Therefore a local interface should suffice.
> > I basically had the same idea like you when I implemented the interface
> > for APM years ago. My first implementation used an extension however it
> > didn't seem to make much sense in using an X client which would communicate
> > with the server just to send information across that could be obtained
> > by the Xserver itself.
> > Therefore I decided to add an interface to the DDX splitting it into
> > a OS independent and OS dependent part.
>
> Even if you only need local access, I think it makes sense to implement
> it as an X request. This avoids adding another ad-hoc IPC mechanism;
> you could create a unix socket and make a protocol for sending these
> requests back and forth, but I'ld rather just sidestep possible security
> implications and use what is already in place.
We should evaluate both possibilities.
>
> But I think there might be a case for remote access, e.g. if you run a
> remote X session and the client wants to add/remove devices...
>
Hm, that is a different issue I think. Devices need to be detected locally.
Wether we want to advertise new devices to Xservers and have a mechanism by
which clients can tell the Xserver to open a specific device is a different
story.
Egbert.
From krahn at niehs.nih.gov Fri Jul 2 09:21:34 2004
From: krahn at niehs.nih.gov (Joe Krahn)
Date: Fri Jul 2 09:22:23 2004
Subject: [Xorg] XINPUT additions; maybe add an XDEVICE extension?
In-Reply-To: <16613.25143.44541.395195@xf11.fra.suse.de>
References: <40D9BFAE.8060801@bitplanet.net> <16607.59124.921806.956671@herme
s.local> <40E15455.9060104@bitplanet.net>
<16613.25143.44541.395195@xf11.fra.suse.de>
Message-ID: <40E58B8E.1000509@niehs.nih.gov>
A lot of XINPUT commands are written as if they were made as
interfaces to X extensions in general. For example, XINPUT
defines XSelectExtensionEvent(), which is (I think) the only
standard interface to non-hardwired extension event types.
Also, many input devices are really output devices as well,
even in XINPUT which defines output as Feedback events.
IMHO, XINPUT should really be XDEVICE. But, XINPUT is
already well established. So, perhaps a development plan
could be to add a new extension called XDEVICE that
does all of the device managament and configuration, and
could be designed not just for input devices, but for any
device.
Regardless, XINPUT itself still needs some updating.
Joe
From krh at bitplanet.net Fri Jul 2 09:43:26 2004
Date: Fri Jul 2 09:45:01 2004
Subject: [Xorg] Wiki page for XInput hotplug work
Message-ID: <40E590AE.40600@bitplanet.net>
Hi,
I've set up a wiki page for the XInput hotplug work:
http://freedesktop.org/XOrg/XInputHotplug
For now it's just a summary of the discussion so far. Several people
have expressed that the XInput specification and implementation is
lacking or incomplete in places. If people could add details to the
wiki page or just follow up to this mail, that would be cool. I would
like to collect a list of XInput issues, so we can discuss what needs to
added/fixed besides the hotplug stuff.
Kristian
Date: Fri Jul 2 09:47:06 2004
Subject: [Xorg] The big multiconsole nasty
In-Reply-To: keithp@keithp.com wrote on Tuesday,
29 June 2004 at 11:56:58 -0700
References: <1088522150.32425.7.camel@localhost.localdomain>
<E1BfNnC-0000bf-N1@evo.keithp.com>
Keith Packard writes:
>
> Around 16 o'clock on Jun 29, Alan Cox wrote:
>
> > 1. Multiple video cards means making RAC work across *multiple* X
> > servers running at once on a system each with its own console
>
> A significant amount of the RAC effort involves sharing the standard VGA
> I/O port and video memory addresses; if we accept that supporting multiple IS
A
> video cards isn't along the critical path, we can probably delay a large
> portion of this work and focus only on getting cards POSTed at boot time.
We have never been able to support multiple ISA video cards.
However RAC is an importand issue for a lot of PCI (AGP) graphics cards
at least during initialization.
>
> > 3. Borrowing things like BIOS mode switch functionality is going to
> > get really hairy.
>
> But may well be necessary for the forseeable future -- Intel has no
> current plan to document the i810 (et al) mode selection code, so we're
> stuck with using the BIOS.
It is not only Intel that creates these problems. For many brand new video
cards the VESA driver is the only option. Distributors like to use the
VESA driver as fallback to give customers a grapical login - even if there
isn't a native driver around.
no grapical login == very unhappy customer
>
> Seems like we need some level of kernel arbitration to keep the system
> stable; it could be as little as some PCI remapping ioctls and a little
> lock for shared regions.
>
We should not need any PCI remapping if the kernel itself does the right
mapping. The remapping in the Xserver originated in the days when kernels
didn't do any PCI validations and BIOSes were were not able to map multiple
graphics cards correctly.
What we may need is an IOCTL to set VGA routing on bridges.
Egbert.
Date: Fri Jul 2 09:52:36 2004
In-Reply-To: krh@bitplanet.net wrote on Tuesday,
29 June 2004 at 12:08:26 +0200
References: <40D9BFAE.8060801@bitplanet.net> <E1BdfYK-0000UK-Kd@evo.keithp.com>
<16608.14200.939504.532986@hermes.local>
<40E13F9A.7030108@bitplanet.net>
Kristian H=F8gsberg writes:
> Egbert Eich wrote:
> > Keith Packard writes:
> > > =
> > > Around 19 o'clock on Jun 23, =3D?ISO-8859-1?Q?Kristian_H=3DF8gsbe=
rg?=3D wrote:
> > > =
> > > > The overall design I'm thinking of is to keep the device discov=
ery =
> > > > mechanism out of the X server.
> > > =
> > > I think that's probably the right design.
> > =
> > Provided it is generic and not X specific. =
> =
> The main idea behind keeping the discovery mechanism out of the server=
=
> was that different systems can use different mechanisms. On GNOME or =
> KDE desktops I think it would make good sense to use HAL for detection=
=
> (which is generic and system-wide), but an embedded system may well wa=
nt =
> to use something more lean.
It depends on if you want to implement different system specific mechanis=
ms
into the clients by adding them to the toolkits or if you want to abstrac=
t
away things from the clients (and the toolkits) by putting the system
dependent functionality into one central place (the Xserver) which expos=
es
a uniform interface to its clients.
So far the paradigm was to do the latter. =
The advantage of this was (and the reason for the paradigm) that all clie=
nts
(including those which where not written using any major toolkit) only ha=
d
to be developed for a single interface.
This is even more importand in a heterogenious networked environment.
If the discovery mechanism was to be integrated into the client the clien=
t
would have to be able to talk to all the different systems and all detect=
ion
mechansims would have to be network transparent.
Therefore the Xserver would obtain information about new input devices
locally and advertise newly added devices to interested clients thru
the XInput extension. The client could advice the Xserver to 'grab'
the device and keep it until either the client or the Xserver terminates
(and automatically reclaim it when replugged) or the device is unplugged =
(policy depends on the environment).
> =
> Also, by moving the mechanism to an X client daemon, you can implement=
=
> desktop specific policy in the daemon. For example, in the GNOME =
> environment you could have a daemon that reads per user settings for =
> input devices from GConf.
It would require the X client daemon to run on the machine the Xserver is=
running on or the discovery mechanism would have to be network transparen=
t.
We should explore if we cannot achive the same thing by designing an
X abstraction for the device detection carefully that we can implement
a policy on top.
In the past this has not always been done, rather X extensions often
were designed in a way to meet exactly the specific requirements at
the time.
> > =
> > When we do this we should try to fix other issues with the XInput
> > extension. It's a while back since I've looked at it but there are
> > some things that immediately strike ones eyes just reading the specs=
=2E
> =
> Do you remember what specifically was the problem? I was thinking of =
> adding a link to a new XInput page in the "Development" section on =
> http://freedesktop.org/XOrg, is that okay? We could use that for =
> collecting the suggestions that come up.
> =
That sounds like a good idea.
What I remember right now:
1.a. Clearify meaning of device type and device name in the XDeviceInfo =
struct. Type is an Atom form a fixed list. =
b. A device type touchpad is meaningless as it doesn't describe what =
device (stylus, eraser, mouse etc.) is attached.
2. Make device controls more flexible. A device control currently =
is an XID. Make it an Atom.
Egbert.
Date: Fri Jul 2 10:05:37 2004
In-Reply-To: alan@lxorguk.ukuu.org.uk wrote on Tuesday,
29 June 2004 at 16:15:52 +0100
References: <E1Bf7ts-0000Vq-9K@evo.keithp.com>
<B9340A20-C9D6-11D8-A10A-00039390D626@pepper.com>
<8D0EF8DF-C9DF-11D8-A10A-00039390D626@pepper.com>
<1088522150.32425.7.camel@localhost.localdomain>
Alan Cox writes:
> Well actually there are two or three related issues here
>
> 1. Multiple video cards means making RAC work across *multiple* X
> servers running at once on a system each with its own console
Right. That is currently the biggest showstopper to get multi seat
working. One could use an external deamon to handle locking between
servers or a kernel module.
>
> 2. PCI config has to go via the kernel, including some kind of
> arbitration for VGA enables. Bashing PCI config ports directly will
> crash machines and (I'm told) also lead to memory and I/O corruption
> on AMD64 IOMMU..
Do you refer to config port access directly thru the 'well known' 'config
mechanism 1' (ie PIO 0xcf8 0xcfc registers), or do you mean access to
PCI config space from user space altogether - even when using the kernel
functions?
>
> 3. Borrowing things like BIOS mode switch functionality is going to
> get really hairy.
>
> Has anyone in the original design of the resource arbitration logic
> considered the multi-server issue ?
Yes - after we have gotten thru with the present design :-/
I have spent some time and thoughts on this issue:
My conclusion was that one should move the entire device and
chipset probing (currently Probe() and PreInit() in the X drivers)
to an external deamon. This would also take care of the access control
among different Xserver instances.
Cheers,
Egbert.
From keithp at keithp.com Fri Jul 2 10:51:12 2004
From: keithp at keithp.com (Keith Packard)
Date: Fri Jul 2 10:51:27 2004
In-Reply-To: Your message of "Fri, 02 Jul 2004 18:41:35 +0200."
<16613.36927.224614.633810@xf11.fra.suse.de>
Message-ID: <E1BgSBu-0006Va-LW@evo.keithp.com>
Around 18 o'clock on Jul 2, Egbert Eich wrote:
> We have never been able to support multiple ISA video cards.
> However RAC is an importand issue for a lot of PCI (AGP) graphics cards
> at least during initialization.
Ok; I didn't understand the limits of ISA card access; having
(fortunately) never used a computer with an ISA video card...
And, of course we need some way to touch the VGA I/O ports on arbitrary
video cards (I believe some S3 cards must be poked in I/O ports before
they enable MMIO register access).
> It is not only Intel that creates these problems. For many brand new video
> cards the VESA driver is the only option.
Right; you can either use the VESA X driver or the VESA fbdev kernel
driver. I mostly wanted to note that even "vendor" drivers can rely on
the BIOS for mode selection, which is pretty harsh.
> We should not need any PCI remapping if the kernel itself does the right
> mapping.
I thought the problem was that sometimes the kernel can't know what address
range is needed by an arbitrary card -- motherboard and video card bugs
sometimes mean that only a subset of the video memory ends up getting
mapped by the time the X server starts. Without some way to ask the kernel
to remap things, it wouldn't be possible to fix this safely from user-mode.
> What we may need is an IOCTL to set VGA routing on bridges.
I'd sure rather see the X server not need to understand the whole PCI bus
layout...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/418d9f7b/attach
ment.pgp
Date: Fri Jul 2 10:56:15 2004
<16613.38298.894898.456797@xf11.fra.suse.de>
Message-ID: <E1BgSGZ-0006W9-Hw@evo.keithp.com>
> My conclusion was that one should move the entire device and
> chipset probing (currently Probe() and PreInit() in the X drivers)
> to an external deamon. This would also take care of the access control
> among different Xserver instances.
Would you also consider moving the mode configuration logic to this
daemon? With that in place, the mode selection would no longer be tied to
the X server itself so that other systems could take advantage of it.
I'm particularily interested in getting mesa-solo running for some cards.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/a8934fbd/attach
ment.pgp
Date: Fri Jul 2 11:07:51 2004
<16613.37517.83485.101157@xf11.fra.suse.de>
Message-ID: <E1BgSRf-0006Z6-JQ@evo.keithp.com>
> It depends on if you want to implement different system specific mechanisms
> into the clients by adding them to the toolkits or if you want to abstract
> away things from the clients (and the toolkits) by putting the system
> dependent functionality into one central place (the Xserver) which exposes
> a uniform interface to its clients.
These aren't incompatible; the common interface for clients remain the X
input extension.
How the X server discovers available devices and collects data for and
about them will remain somewhat system dependent. The suggestion here is to
modify how the X server learns about devices; currently it's "magic", and
so desktop software has no standard way to fix or change the behaviour.
We can either have the X server provide some new standard protocol for
applications to configure the set of devices the X server should use, or
we can just use the X protocol for that purpose. Either is functionaly
equivalent, I think both present similar security "challenges". I think
using the X protocol will be somewhat easier to implement and will
trivially provide network transparency for this configuration.
That's just my first opinion though; it wouldn't take a lot of data to
force this to be reevaluated...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/cd0a5dff/attach
ment.pgp
From alan at lxorguk.ukuu.org.uk Fri Jul 2 10:06:36 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri Jul 2 11:09:33 2004
<16613.38281.414846.796738@xf11.fra.suse.de>
Message-ID: <1088787996.7263.19.camel@localhost.localdomain>
On Gwe, 2004-07-02 at 18:04, Egbert Eich wrote:
> Do you refer to config port access directly thru the 'well known' 'config
> mechanism 1' (ie PIO 0xcf8 0xcfc registers), or do you mean access to
> PCI config space from user space altogether - even when using the kernel
> functions?
Using conf1. Accessing via the kernel provided functions is fine
From erikharrison at gmail.com Fri Jul 2 13:50:55 2004
From: erikharrison at gmail.com (Erik Harrison)
Date: Fri Jul 2 13:51:32 2004
Subject: [Xorg] getconfig.pl
Message-ID: <5b18a542040702135027d7c04d@mail.gmail.com>
I was frustrated the other day by my seeming inability to learn C. As
I actually speak Perl and was hoping for some distraction, is started
to poke around in getconfig.pl.
getconfig has a small list of PCI ID to driver mappings inside the
program itself. Considering that we install a default xorg.cfg file,
is it really sane to keep this information in getconfig? I could move
it out into xorg.cfg if it's the Right Thing.
-Erik
From vektor at dumbterm.net Fri Jul 2 14:55:37 2004
From: vektor at dumbterm.net (Billy Biggs)
Date: Fri Jul 2 14:55:43 2004
Subject: [Xorg] XVIDEO memory problems under Xorg
Message-ID: <20040702215537.GA2880@dumbterm.net>
Hi,
I am wondering if someone who is familiar with Xorg vs XFree86 in
terms of XVIDEO could take a look at this bug:
http://freedesktop.org/bugzilla/show_bug.cgi?id=474
Basically, users of both the ATI binary drivers and the Matrox driver
are complaining that XVIDEO applications can't be run until they shut
down pixmap-eating apps like Mozilla. This problem does not seem to
occur under XFree86 (or at least, not nearly as frequently). I hear a
lot of complaints from FC2 users about this bug.
Is there something that changed in how video memory is being
allocated between the two X servers?
Thanks,
-Billy
From andrew at digital-domain.net Fri Jul 2 15:33:23 2004
From: andrew at digital-domain.net (Andrew Clayton)
Date: Fri Jul 2 15:33:27 2004
In-Reply-To: <20040702215537.GA2880@dumbterm.net>
References: <20040702215537.GA2880@dumbterm.net>
Message-ID: <1088807602.2204.33.camel@alpha.digital-domain.net>
On Fri, 2004-07-02 at 22:55, Billy Biggs wrote:
> Hi,
>
> I am wondering if someone who is familiar with Xorg vs XFree86 in
> terms of XVIDEO could take a look at this bug:
>
> http://freedesktop.org/bugzilla/show_bug.cgi?id=474
>
> Basically, users of both the ATI binary drivers and the Matrox driver
> are complaining that XVIDEO applications can't be run until they shut
> down pixmap-eating apps like Mozilla. This problem does not seem to
> occur under XFree86 (or at least, not nearly as frequently). I hear a
> lot of complaints from FC2 users about this bug.
I had no problems with XFree86 4.3 under FC1 (or any previous version)
but this problem showed up with Xorg under FC2. I have seen similar
reports against XFree86 4.4 on the XFree86 mailing list. Looks like
something happened between XFree86 4.3 and 4.4, which is also around the
time the Xorg code was forked off.
>
> Is there something that changed in how video memory is being
> allocated between the two X servers?
>
> Thanks,
> -Billy
>
Cheers,
--
Andrew Clayton
From daniel at freedesktop.org Sat Jul 3 00:34:10 2004
Date: Sat Jul 3 00:34:13 2004
Subject: [Xorg] [behdad@cs.toronto.edu: [fdo] Updated syncmail script for
new CVS loginfo syntax]
Message-ID: <20040703073410.GK4379@fooishbar.org>
----- Forwarded message from Behdad Esfahbod <behdad@cs.toronto.edu> -----
Date: Sat, 3 Jul 2004 02:11:25 -0400
From: Behdad Esfahbod <behdad@cs.toronto.edu>
To: freedesktop@freedesktop.org
Message-ID: <Pine.LNX.4.58.0407030202190.15549@epoch.cs>
Subject: [fdo] Updated syncmail script for new CVS loginfo syntax
List-Id: "General discussion about freedesktop.org"
<freedesktop.freedesktop.org>
Hi,
If you are getting tired of being teased about updating your
syncmail script to the new CVS loginfo syntax, this mail is for
you.
If you have opted to use the CIA script, you have already
switched to the new loginfo format. If not, you need to do now.
For that you need to add
UseNewInfoFmtStrings=yes
to the CVS config file. Then if you have script using the old
format you can escape it by using 1 after the % ie:
ALL $CVSROOT/CVSROOT/syncmail %1{sVv} fribidi-commit@pdx.freedesktop.org
After changing all of them, you still get teased by another
warning message, suggesting you rewrite your scripts to use the
new format. I did it for syncmail script and you can just copy.
I changed the name of the script from 'syncmail' to 'maildiff',
because I had to change the usage syntax. So what you need to do
is:
1. Import maildiff in CVSROOT of your project (you probably want
to add it to the checkoutlist too, and also removing old
syncmail). Get maildiff from
pdx.freedesktop.org:/cvs/fribidi/CVSROOT/maildiff
2. Replace the syncmail line in loginfo by:
ALL $CVSROOT/CVSROOT/maildiff fribidi-commit@pdx.freedesktop.org %{sVv} %p
That's all.
Note that you cannot use "%s" with maildiff anymore. Instead,
you can use the same script and loginfo file with both the new
loginfo format and the old one.
Cheers,
--behdad
behdad.org
_______________________________________________
freedesktop mailing list
freedesktop@freedesktop.org
http://freedesktop.org/mailman/listinfo/freedesktop
----- End forwarded message -----
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040703/f3759a61/attach
ment.pgp
Date: Sat Jul 3 00:34:22 2004
Subject: [Xorg] [behdad@cs.toronto.edu: Re: [fdo] Updated syncmail script
for new CVS loginfo syntax]
Message-ID: <20040703073422.GL4379@fooishbar.org>
----- Forwarded message from Behdad Esfahbod <behdad@cs.toronto.edu> -----
Date: Sat, 3 Jul 2004 02:20:04 -0400
From: Behdad Esfahbod <behdad@cs.toronto.edu>
To: freedesktop@freedesktop.org
Subject: Re: [fdo] Updated syncmail script for new CVS loginfo syntax
Message-ID: <Pine.LNX.4.58.0407030219080.15549@epoch.cs>
List-Id: "General discussion about freedesktop.org"
<freedesktop.freedesktop.org>
On Sat, 3 Jul 2004, it was written:
> ALL $CVSROOT/CVSROOT/maildiff fribidi-commit@pdx.freedesktop.org %{sVv} %p
Oops, it should be:
ALL $CVSROOT/CVSROOT/maildiff fribidi-commit@pdx.freedesktop.org -- %{sVv} %p
Cheers,
--behdad
_______________________________________________
freedesktop mailing list
freedesktop@freedesktop.org
http://freedesktop.org/mailman/listinfo/freedesktop
----- End forwarded message -----
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040703/86df7c62/attach
ment.pgp
From gene.heskett at verizon.net Sat Jul 3 02:24:18 2004
From: gene.heskett at verizon.net (Gene Heskett)
Date: Sat Jul 3 02:24:25 2004
Subject: [Xorg] OT:oddity in Mesa-6.0.1
Message-ID: <200407030524.19137.gene.heskett@verizon.net>
Greetings; Off topic, but the brains are here :)
XFree86-4.3 system on linux-2.6.7-mm3, rh8 updated to fedora Core 1
Nvidia GForce2 MX200 card, 32 megs, using the 'nv' driver.
I just installed (I think) the MesaLibs-6-0-1, and MesaDemos-6.0.1
tarballs with the cli command line of "make linux-x86" after
unpacking both archives into the same dir. There doesn't appear to
be a seperate "make install" directive that I could find, the docs
are obviously wwaaaayyyyyyy out of date.
Restarted X after the build.
Old installed Mesa was:
[root@coyote root]# glxinfo
name of display: :0.0
Xlib: extension "XFree86-DRI" missing on display ":0.0".
display: :0 screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX extensions:
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract,
GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
And gives a table of data I didn't paste.
The reloading of X apparently used the older versions because the data
returned from glxinfo is exactly the same as before. And glxgears,
at its default small window size, toddles along at around 170fps,
dropping to 30 or so if I bring it up to 1/4 screen on a 1600x1200x32
bit screen. Within tolerances, thats also exactly as before.
Is there a need to rerun ldconfig, or adjust something in my
XF86Config? It currently has (and no errors are shown in the log)
Section "Module"
# Load "record" # X event recorder
# You only need the following two modules if you do not use
xfs.
# Load "freetype" # TrueType font handler
# Load "type1" # Adobe Type 1 font handler
Load "dbe" # Double-buffering
Load "GLcore" # OpenGL support
Load "dri" # Direct rendering infrastructure
Load "glx" # OpenGL X protocol interface
Load "extmod" # Misc. required extensions
Load "v4l" # Video4Linux
EndSection
Any hints will be much appreciated as tuxracer doesn't run,
complaining:
Humm, I'll be dipped, now it does, but extremely slow, mouse motions
are delayed several seconds on screen. Obviously no acceleration.
But the music works and I was eventually able to find the quit button
with the mouse.
Is there any hope here, short of installing the latest nvidia-6106
drivers?
--
Cheers, Gene
There are 4 boxes to be used in defense of liberty.
Soap, ballot, jury, and ammo.
Please use in that order, starting now. -Ed Howdershelt, Author
Additions to this message made by Gene Heskett are Copyright 2004,
Maurice E. Heskett, all rights reserved.
From breun at xs4all.nl Sat Jul 3 07:21:13 2004
From: breun at xs4all.nl (Nils Breunese)
Date: Sat Jul 3 07:21:18 2004
Subject: [Xorg] Pixmap 24/32 on dual videocard system
Message-ID: <40E6C0D9.4000807@xs4all.nl>
I run X.org 6.7.0-5 with two videocards (AGP nvidia and an old PCI SiS)
in my system. I used to run XFree86 on my system and those two
videocards worked fine. Then I switched to X.org, but ever since I don't
seem to be able to get both cards working simultaneously in X.
I have this in my /etc/X11/xorg.conf:
Section "ServerFlags"
Option "Pixmap" "32"
EndSection
When the Pixmap option is set to 32 and I start X only the monitor
attached to my nvidia card comes up. In /var/log/Xorg.0.log I find the
following error:
(EE) SIS(1): Driver can't support depth 24 pixmap format (32)
(EE) SIS(1): **************************************************
(EE) SIS(1): ERROR:
(EE) SIS(1): xf86SetDepthBpp() error
(EE) SIS(1): END OF MESSAGE
(EE) SIS(1): **************************************************
However, when I change the Pixmap option to 24 only the monitor
connected to my SiS card works and /var/log/Xorg.0.log reads:
(EE) NVIDIA(0): Driver can't support depth 24 pixmap format (24)
(Doesn't matter if I use the X.org nv driver or nvidia's binary release).
My question is: is there a way to get both working under X.org? Can I
specify different pixmap values for each card? If so, how? Any other
suggestions?
Thanks,
Nils.
--
"I got a funny feeling they got plastic in the afterlife" - Beck
-------------- next part --------------
# XFree86 4 configuration _not_ created by redhat-config-xfree86
Section "ServerLayout"
# Option "Xinerama" "On" # Geeft rare artefacten in menu?
Identifier "Default Layout"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "DevInputMice" "AlwaysCore"
EndSection
Option "Pixmap" "32"
EndSection
Section "Files"
# RgbPath is the location of the RGB database. Note, this is the name of the
# file minus the extension (like ".txt" or ".db"). There is normally
# no need to change the default.
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.
RgbPath "/usr/X11R6/lib/X11/rgb"
FontPath "unix/:7100"
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "fbdevhw"
Load "glx" # OpenGL (nvidia driver)
Load "record"
Load "speedo" # ?
Load "xtrap" # ?
# Load "freetype" # Not needed when using xfs
# Load "type1" # Not needed when using xfs
# Load "dri" # Disable when using nvidia driver
EndSection
Section "InputDevice"
# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
# Option "Xleds" "1 2 3"
# To disable the XKEYBOARD extension, uncomment XkbDisable.
# Option "XkbDisable"
# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults). For example, for a non-U.S.
# keyboard, you will probably want to use:
# Option "XkbModel" "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
# Option "XkbModel" "microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
# Option "XkbLayout" "de"
# or:
# Option "XkbLayout" "de"
# Option "XkbVariant" "nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
# Option "XkbOptions" "ctrl:swapcaps"
# Or if you just want both to be control, use:
# Option "XkbOptions" "ctrl:nocaps"
#
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbModel" "logiaccess"
Option "XkbLayout" "us_intl"
EndSection
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "no"
EndSection
# If the normal CorePointer mouse is not a USB mouse then
# this input device can be used in AlwaysCore mode to let you
# also use USB mice at the same time.
Identifier "DevInputMice"
Driver "mouse"
Option "Emulate3Buttons" "no"
EndSection
Section "Monitor"
#DisplaySize 330 250 # mm
Identifier "Monitor0"
VendorName "LG"
ModelName "775N"
HorizSync 30.0 - 70.0
VertRefresh 50.0 - 160.0
Option "dpms"
EndSection
Section "Monitor"
#DisplaySize 240 180 # mm
VendorName "Compaq"
ModelName "11"
HorizSync 31.5 - 37.9
VertRefresh 50.0 - 70.0
Option "dpms"
EndSection
Section "Device"
### Available Driver options are:-
### Values: : integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "SWcursor" # [<bool>]
#Option "HWcursor" # [<bool>]
#Option "NoAccel" # [<bool>]
#Option "ShowCache" # [<bool>]
#Option "ShadowFB" # [<bool>]
#Option "UseFBDev" # [<bool>]
#Option "Rotate" # [<str>]
#Option "VideoKey" # 
#Option "FlatPanel" # [<bool>]
#Option "FPDither" # [<bool>]
#Option "CrtcNumber" # 
Identifier "Card0"
Driver "nvidia"
VendorName "nVidia Corporation"
BoardName "NV17 [GeForce4 MX 440]"
BusID "PCI:1:0:0"
Option "NoLogo" "True"
Option "TwinView"
Option "TwinViewOrientation" "Clone"
Option "TVStandard" "PAL-G"
Option "TVOutFormat" "COMPOSITE"
Option "TVOverScan" "1.0"
Option "SecondMonitorHorizSync" "30-50"
Option "SecondMonitorVertRefresh" "60"
Option "MetaModes" "1280x1024, 800x600 @1280x1024; 1152x864, 800x60
0 @1152x864; 1024x768, 800x600 @1024x768; 800x600, 800x600; 640x640, 640x640"
EndSection
Section "Device"
#Option "HWcursor" # [<bool>]
#Option "NoAccel" # [<bool>]
#Option "TurboQueue" # [<bool>]
#Option "FastVram" # [<bool>]
#Option "NoHostBus" # [<bool>]
#Option "ForceCRT2Type" # [<str>]
#Option "ShadowFB" # [<bool>]
#Option "Rotate" # [<str>]
#Option "NoXvideo" # [<bool>]
#Option "Vesa" # [<bool>]
#Option "MaxXFBMem" # 
#Option "ForceCRT1" # [<bool>]
#Option "DSTN" # [<bool>]
#Option "XvOnCRT2" # [<bool>]
#Option "PanelDelayCompensation" # 
#Option "TVStandard" # <str>
#Option "UseROMData" # [<bool>]
#Option "NoInternalModes" # [<bool>]
#Option "UseOEMData" # [<bool>]
#Option "BIOSFile" # <str>
#Option "NoYV12" # [<bool>]
#Option "CHTVType" # [<bool>]
#Option "CHTVOverscan" # [<bool>]
#Option "CHTVSuperOverscan" # [<bool>]
#Option "CHTVLumaBandwidthCVBS" # 
#Option "CHTVLumaBandwidthSVIDEO" # 
#Option "CHTVLumaFlickerFilter" # 
#Option "CHTVChromaBandwidth" # 
#Option "CHTVChromaFlickerFilter" # 
#Option "CHTVCVBSColor" # [<bool>]
#Option "CHTVTextEnhance" # 
#Option "CHTVContrast" # 
#Option "SISTVEdgeEnhance" # 
#Option "SISTVAntiFlicker" # 
#Option "SISTVSaturation" # 
#Option "TVXPosOffset" # 
#Option "TVYPosOffset" # 
#Option "SIS6326TVAntiFlicker" # <str>
#Option "SIS6326TVEnableYFilter" # [<bool>]
#Option "SIS6326TVYFilterStrong" # [<bool>]
#Option "UseColorHWCursor" # [<bool>]
#Option "ColorHWCursorBlending" # [<bool>]
#Option "ColorHWCursorBlendThreshold" # 
#Option "RestoreBySetMode" # [<bool>]
Identifier "Card1"
Driver "sis"
VendorName "Silicon Integrated Systems [SiS]"
BoardName "86C326 5598/6326"
BusID "PCI:0:12:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 1
EndSubSection
Depth 4
EndSubSection
Depth 8
EndSubSection
Depth 15
EndSubSection
Depth 16
EndSubSection
Depth 24
Modes "1152x864" "1024x768" "800x600"
EndSubSection
EndSection
Section "Screen"
Device "Card1"
Monitor "Monitor1"
DefaultDepth 24
Depth 1
EndSubSection
Depth 4
EndSubSection
Depth 8
EndSubSection
Depth 15
EndSubSection
Depth 16
EndSubSection
Depth 24
Modes "1024x768" "800x600"
EndSubSection
EndSection
Section "DRI"
Group 0
Mode 0666
EndSection
From brian.paul at tungstengraphics.com Sat Jul 3 08:36:25 2004
Date: Sat Jul 3 08:41:44 2004
Subject: [Xorg] OT:oddity in Mesa-6.0.1
In-Reply-To: <200407030524.19137.gene.heskett@verizon.net>
References: <200407030524.19137.gene.heskett@verizon.net>
Message-ID: <40E6D279.9030004@tungstengraphics.com>
Gene Heskett wrote:
> Greetings; Off topic, but the brains are here :)
>
> XFree86-4.3 system on linux-2.6.7-mm3, rh8 updated to fedora Core 1
>
> Nvidia GForce2 MX200 card, 32 megs, using the 'nv' driver.
>
> I just installed (I think) the MesaLibs-6-0-1, and MesaDemos-6.0.1
> tarballs with the cli command line of "make linux-x86" after
> unpacking both archives into the same dir.
OK, so that build's the software renderer (no hardware acceleration).
> There doesn't appear to
> be a seperate "make install" directive that I could find, the docs
> are obviously wwaaaayyyyyyy out of date.
The Mesa Compilation/Install page (on the website and in the distro)
explains how/where to install the headers and libs. Which docs are
you looking at?
> Restarted X after the build.
>
> Old installed Mesa was:
> [root@coyote root]# glxinfo
> name of display: :0.0
> Xlib: extension "XFree86-DRI" missing on display ":0.0".
> display: :0 screen: 0
> direct rendering: No
> server glx vendor string: SGI
> server glx version string: 1.2
> server glx extensions:
> GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
> client glx vendor string: SGI
> client glx version string: 1.2
> client glx extensions:
> GLX extensions:
> OpenGL vendor string: Mesa project: www.mesa3d.org
> OpenGL renderer string: Mesa GLX Indirect
> OpenGL version string: 1.3 Mesa 4.0.4
> OpenGL extensions:
> GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
> GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
> GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
> GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
> GL_EXT_blend_minmax, GL_EXT_blend_subtract,
> GL_EXT_texture_env_add,
> GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
> GL_EXT_texture_lod_bias
> glu version: 1.3
> glu extensions:
> GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
This indicates that you're using the stock XFree86/Xorg libGL (not the
Mesa libGL you built above) and that you're using indirect rendering
(no hardware acceleration).
> And gives a table of data I didn't paste.
>
> The reloading of X apparently used the older versions because the data
> returned from glxinfo is exactly the same as before. And glxgears,
> at its default small window size, toddles along at around 170fps,
> dropping to 30 or so if I bring it up to 1/4 screen on a 1600x1200x32
> bit screen. Within tolerances, thats also exactly as before.
>
> Is there a need to rerun ldconfig, or adjust something in my
> XF86Config? It currently has (and no errors are shown in the log)
>
> Section "Module"
> # Load "record" # X event recorder
> # You only need the following two modules if you do not use
> xfs.
> # Load "freetype" # TrueType font handler
> # Load "type1" # Adobe Type 1 font handler
> Load "dbe" # Double-buffering
> Load "GLcore" # OpenGL support
> Load "dri" # Direct rendering infrastructure
> Load "glx" # OpenGL X protocol interface
> Load "extmod" # Misc. required extensions
> Load "v4l" # Video4Linux
> EndSection
>
> Any hints will be much appreciated as tuxracer doesn't run,
> complaining:
>
> Humm, I'll be dipped, now it does, but extremely slow, mouse motions
> are delayed several seconds on screen. Obviously no acceleration.
> But the music works and I was eventually able to find the quit button
> with the mouse.
>
> Is there any hope here, short of installing the latest nvidia-6106
> drivers?
If you have an NVIDIA card and want hardware OpenGL, you have no
choice but to install NVIDIA's driver package. You'll have to update
your XF86Config file (if the driver installation doesn't do it
automatically) to disable DRI (at least).
-Brian
From krh at bitplanet.net Sat Jul 3 08:52:24 2004
Date: Sat Jul 3 08:53:53 2004
References: <40D9BFAE.8060801@bitplanet.net> <E1BdfYK-0000UK-Kd@evo.keithp.co
m> <16608.14200.939504.532986@hermes.local> <40E13F9A.7030108@bitpla
net.net>
<16613.36429.355137.54150@xf11.fra.suse.de>
Message-ID: <40E6D638.7060501@bitplanet.net>
Egbert Eich wrote:
> Kristian H?gsberg writes:
> > Egbert Eich wrote:
> > > Keith Packard writes:
> > > >
> > > > Around 19 o'clock on Jun 23, =?ISO-8859-1?Q?Kristian_H=F8gsberg?= wrot
e:
> > > >
> > > > > The overall design I'm thinking of is to keep the device discovery
> > > > > mechanism out of the X server.
> > > >
> > > > I think that's probably the right design.
> > >
> > > Provided it is generic and not X specific.
> >
> > The main idea behind keeping the discovery mechanism out of the server
> > was that different systems can use different mechanisms. On GNOME or
> > KDE desktops I think it would make good sense to use HAL for detection
> > (which is generic and system-wide), but an embedded system may well want
> > to use something more lean.
>
> It depends on if you want to implement different system specific mechanisms
> into the clients by adding them to the toolkits or if you want to abstract
> away things from the clients (and the toolkits) by putting the system
> dependent functionality into one central place (the Xserver) which exposes
> a uniform interface to its clients.
It wasn't my intention that all clients should use the hotplug requests,
only the input device hotplug daemon. Toolkit support should not be
necessary either, you would use the XInput Xlib API directly. This way
you still have system dependent functionality in one central place, it's
just not in the X server but in the hotplug daemon.
...
> What I remember right now:
> 1.a. Clearify meaning of device type and device name in the XDeviceInfo
> struct. Type is an Atom form a fixed list.
> b. A device type touchpad is meaningless as it doesn't describe what
> device (stylus, eraser, mouse etc.) is attached.
Yeah, this bit from xf86Xinput.c:xf86ActivateDevice() doesn't help:
local->atom = MakeAtom(local->name,
strlen(local->name),
TRUE);
AssignTypeAndName (dev, local->atom, local->name);
i.e. it creates a atom for the device name and uses it as the type :-/.
Here's output from a modified xsetpointer -l:
"Mouse0" XID=3, type=Mouse0 (115) [XPointer]
"keyboard" XID=4, type=NULL (0) [XKeyboard]
"stylus" XID=2, type=stylus (114) [XExtensionDevice]
"eraser" XID=1, type=eraser (113) [XExtensionDevice]
"cursor" XID=0, type=cursor (112) [XExtensionDevice]
> 2. Make device controls more flexible. A device control currently
> is an XID. Make it an Atom.
Can this be done in a backward compatible way or would we need a new
request? Btw, why is the device control both in the
XChangeDeviceControl() argument list and in the XDeviceControl struct?
That's redundant...
Kristian
From footourist at gmail.com Sat Jul 3 09:03:14 2004
From: footourist at gmail.com (Hagbard Celine)
Date: Sat Jul 3 09:03:47 2004
Subject: [Xorg] fdo xserver broken with glx
Message-ID: <2d429e9d0407030903704be9d4@mail.gmail.com>
Hi,
I'm trying to compile fdo xserver.
Using the script xserver-inst.sh everything goes well and the Xvesa
starts with few and weird colors but starts. Proud of this success I
tryed to compile the xserver with dri (ok) and glx (problems) enabled.
The error I got is:
if gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I../../GL/glx
-I../../GL/include -I../../GL/mesa/include -I../../GL/mesa/X
-I../../mi -I../../Xext -I../../render -I../../../Mesa/include
-I../../../Mesa/src/mesa -I../../../Mesa/src/mesa/main
-I../../../Mesa/src/mesa/glapi -I../../../Mesa/src/mesa/drivers/x11
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing
-D_XOPEN_SOURCE -D_BSD_SOURCE -I/opt/fdo/include
-I/opt/fdo/include/X11/fonts -I/opt/fdo/include/X11/Xtrans
-I../../include -I../../Xext -UHAVE_CONFIG_H -DGLXEXT -DXF86DRI
-DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DXFree86Server
-g -O2 -MT libglcore_a-xf86glx_util.o -MD -MP -MF
".deps/libglcore_a-xf86glx_util.Tpo" -c -o libglcore_a-xf86glx_util.o
`test -f 'X/xf86glx_util.c' || echo './'`X/xf86glx_util.c; \
then mv -f ".deps/libglcore_a-xf86glx_util.Tpo"
".deps/libglcore_a-xf86glx_util.Po"; else rm -f
".deps/libglcore_a-xf86glx_util.Tpo"; exit 1; fi
make[2]: *** No rule to make target
`../../../Mesa/src/mesa/main/arbparse.c', needed by
`libglcore_a-arbparse.o'. Stop.if gcc -DHAVE_CONFIG_H -I. -I.
-I../../include -I../../GL/glx -I../../GL/include
-I../../GL/mesa/include -I../../GL/mesa/X -I../../mi -I../../Xext
-I../../render -I../../../Mesa/include -I../../../Mesa/src/mesa
-I../../../Mesa/src/mesa/main -I../../../Mesa/src/mesa/glapi
-I../../../Mesa/src/mesa/drivers/x11 -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -D_XOPEN_SOURCE -D_BSD_SOURCE
-I/opt/fdo/include -I/opt/fdo/include/X11/fonts
-I/opt/fdo/include/X11/Xtrans -I../../include -I../../Xext
-UHAVE_CONFIG_H -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING
-DGLX_USE_DLOPEN -DGLX_USE_MESA -DXFree86Server -g -O2 -MT
libglcore_a-xf86glx_util.o -MD -MP -MF
".deps/libglcore_a-xf86glx_util.Tpo" -c -o libglcore_a-xf86glx_util.o
`test -f 'X/xf86glx_util.c' || echo './'`X/xf86glx_util.c; \
then mv -f ".deps/libglcore_a-xf86glx_util.Tpo"
".deps/libglcore_a-xf86glx_util.Po"; else rm -f
".deps/libglcore_a-xf86glx_util.Tpo"; exit 1; fi
make[2]: *** No rule to make target
`../../../Mesa/src/mesa/main/arbparse.c', needed by
`libglcore_a-arbparse.o'. Stop.
make[2]: Leaving directory `/home/dasnake/freedesktop.org/xserver/GL/mesa'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dasnake/freedesktop.org/xserver/GL'
make: *** [all-recursive] Error 1
I'm using latest mesa CVS.
The only reference to this error I found googling around is an irc log
of the #dri channel where someone stated that the whole glx part was
broken. Is that still true? I've to compile glx agains some previous
version of mesa?
Thanks,
Hagbard
make[2]: Leaving directory `/home/dasnake/freedesktop.org/xserver/GL/mesa'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/dasnake/freedesktop.org/xserver/GL'
From loc at toya.net.pl Sat Jul 3 09:37:25 2004
Date: Sat Jul 3 09:37:28 2004
In-Reply-To: <2d429e9d0407030903704be9d4@mail.gmail.com>
References: <2d429e9d0407030903704be9d4@mail.gmail.com>
Message-ID: <40E6E0C5.9020709@toya.net.pl>
Hagbard Celine wrote:
> Hi,
>
> I'm trying to compile fdo xserver.
> Using the script xserver-inst.sh everything goes well and the Xvesa
> starts with few and weird colors but starts. Proud of this success I
> tryed to compile the xserver with dri (ok) and glx (problems) enabled.
>
> [...]
> I'm using latest mesa CVS.
>
> The only reference to this error I found googling around is an irc log
> of the #dri channel where someone stated that the whole glx part was
> broken. Is that still true? I've to compile glx agains some previous
> version of mesa?
The newest Mesa CVS has some changes and it won't compile. You can try
an older one but AFAIK glx+dri is broken.
--
Regards,
Jakub Piotr C?apa
From jobi at via.ecp.fr Sat Jul 3 11:42:47 2004
From: jobi at via.ecp.fr (Johan Bilien)
Date: Sat Jul 3 11:42:47 2004
Subject: [Xorg] fd.o xserver and xkb
Message-ID: <20040703184247.GA15564@via.ecp.fr>
Hi,
what is the status of xkb support in the fd.o xserver (kdrive)? Is there
a way to use it? I managed to compile the one included in the xserver
repository, but I could not load it (tried ./Xfbdev -x xkb).
Thanks,
--
Johan
From gene.heskett at verizon.net Sat Jul 3 14:21:47 2004
Date: Sat Jul 3 14:21:52 2004
Subject: [Xorg] More on mesa/NVIDIA
Greetings; Off topic, but this is where the brains live.
I've done the nvidia 6106 install, including the mods to XF86Config,
and its running, but not very fast at all, as in glxgears could run
170-180fps using the kernels nv driver.
Using the nvidia 6106 drivers, glxgears top out at a rather leasurely
90fps maximum. Huh?
The screen looks about the same, but was shifted to the left about an
inch, and whereas tuxracer ran at glacial speeds before, it now
crashes, trashing the screen slightly, but the music continues until
I hit the hardware reset button. A full fsck of this system takes
around 30 minutes, rather like watching varnish dry. Big drive.
Boreing...
At one point in my overgrown nvidia printout it says to make sure that
GLX, NV-GLX, and NVIDIA-GLX extensions are present, something about
using 'xdpyinfo' or some such utility I cannot 'locate', nor is it in
the unpacked today 6106 tree. Does anyone know where that utility
can be obtained from?
Looking at the X log, GLX and NV-GLX are accounted for, but NVIDIA-GLX
didn't answer the roll call.
Further down the page it says I should check /var/log/messages for
NVRM prefixed lines, but thats a no-hitter too.
I still have agpgart in the kernel, and the XF86Config tells nvidia to
use anything it can find with the option '3', so that should be good.
However I can modularize that too if needed.
Going down thru appendix C, the first thing I run into is there seems
to be no /usr/X11R6/lib/libglx.so.*, its totally on the missing list.
Where can I find it?
But I do have the pair of /usr/X11R6/lib/libXvMNVIDIA* things it asks
about next.
/usr/X11R6/lib/modules/drivers/nvidia_drv.o - check
1.0.6106 - check, as is the link from the .so
/usr/lib/libGL* is all present and properly version named
/usr/lib/libGLcore is all there.
The kernel module is there and running or I wouldn't be typeing this
in kmail.
Also, while I was adding the "alias char-major-195-* nvidia" line in
my /etc/modprobe.conf, I found, clear at the bottom of it, this line,
note the missing dash:
alias char-major-195* nvidia
and which I commented out.
So, it appears I'm missing some stuff noted above
in /usr/x11R6/lib/modules/extensions. What did I miss checking so
far?
--
Cheers, Gene
From breun at xs4all.nl Sat Jul 3 15:35:26 2004
Date: Sat Jul 3 15:35:29 2004
In-Reply-To: <40E6EEA5.1060501@winischhofer.net>
References: <40E6C0D9.4000807@xs4all.nl> <40E6EEA5.1060501@winischhofer.net>
Message-ID: <15623.213.84.39.175.1088894126.squirrel@webmail.xs4all.nl>
Thomas Winischhofer wrote:
>> I run X.org 6.7.0-5 with two videocards (AGP nvidia and an old PCI SiS)
>> in my system. I used to run XFree86 on my system and those two
>> videocards worked fine. Then I switched to X.org, but ever since I don't
>> seem to be able to get both cards working simultaneously in X.
>>
>> I have this in my /etc/X11/xorg.conf:
>>
>> Section "ServerFlags"
>> Option "Pixmap" "32"
>> EndSection
>>
>> When the Pixmap option is set to 32 and I start X only the monitor
>> attached to my nvidia card comes up. In /var/log/Xorg.0.log I find the
>> following error:
>>
>> (EE) SIS(1): Driver can't support depth 24 pixmap format (32)
>> (EE) SIS(1): **************************************************
>> (EE) SIS(1): ERROR:
>> (EE) SIS(1): xf86SetDepthBpp() error
>> (EE) SIS(1): END OF MESSAGE
>> (EE) SIS(1): **************************************************
>
> The SiS 6326 does not support 32 bpp (32 bit framebuffer depth).
Apparently, but the nvidia driver also doesn't seem to support 24. Just a
bad combination of videocards then?
> You may try the driver from my website. I think I changed something in
> the bpp setup (conversion flags) that might relate to your problem.
I'm not at home right now, but I'll look into it. Thanks.
Nils.
--
From aritger at nvidia.com Sat Jul 3 15:54:43 2004
From: aritger at nvidia.com (Andy Ritger)
Date: Sat Jul 3 15:55:18 2004
Subject: [Xorg] More on mesa/NVIDIA
Message-ID: <Pine.LNX.4.58.0407031850010.3279@paert.nvidia.com>
The NVIDIA .run package will install NVIDIA's libglx in
/usr/X11R6/lib/modules/extensions/ (not in /usr/X11R6/lib/).
`xdpyinfo` is normally installed in /usr/X11R6/bin/; this is a
standard X utility.
If you'd like to send me your X log file, I can take a look to try
to diagnose what is wrong with your installation.
Thanks,
- Andy
On Sat, 3 Jul 2004, Gene Heskett wrote:
> Greetings; Off topic, but this is where the brains live.
>
> I've done the nvidia 6106 install, including the mods to XF86Config,
> and its running, but not very fast at all, as in glxgears could run
> 170-180fps using the kernels nv driver.
>
> Using the nvidia 6106 drivers, glxgears top out at a rather leasurely
> 90fps maximum. Huh?
>
> The screen looks about the same, but was shifted to the left about an
> inch, and whereas tuxracer ran at glacial speeds before, it now
> crashes, trashing the screen slightly, but the music continues until
> I hit the hardware reset button. A full fsck of this system takes
> around 30 minutes, rather like watching varnish dry. Big drive.
> Boreing...
>
> At one point in my overgrown nvidia printout it says to make sure that
> GLX, NV-GLX, and NVIDIA-GLX extensions are present, something about
> using 'xdpyinfo' or some such utility I cannot 'locate', nor is it in
> the unpacked today 6106 tree. Does anyone know where that utility
> can be obtained from?
>
> Looking at the X log, GLX and NV-GLX are accounted for, but NVIDIA-GLX
> didn't answer the roll call.
>
> Further down the page it says I should check /var/log/messages for
> NVRM prefixed lines, but thats a no-hitter too.
>
> I still have agpgart in the kernel, and the XF86Config tells nvidia to
> use anything it can find with the option '3', so that should be good.
> However I can modularize that too if needed.
>
> Going down thru appendix C, the first thing I run into is there seems
> to be no /usr/X11R6/lib/libglx.so.*, its totally on the missing list.
> Where can I find it?
>
> But I do have the pair of /usr/X11R6/lib/libXvMNVIDIA* things it asks
> about next.
> /usr/X11R6/lib/modules/drivers/nvidia_drv.o - check
> 1.0.6106 - check, as is the link from the .so
> /usr/lib/libGL* is all present and properly version named
> /usr/lib/libGLcore is all there.
>
> The kernel module is there and running or I wouldn't be typeing this
> in kmail.
>
> Also, while I was adding the "alias char-major-195-* nvidia" line in
> my /etc/modprobe.conf, I found, clear at the bottom of it, this line,
> note the missing dash:
>
> alias char-major-195* nvidia
>
> and which I commented out.
>
> So, it appears I'm missing some stuff noted above
> in /usr/x11R6/lib/modules/extensions. What did I miss checking so
> far?
>
> --
> Cheers, Gene
> There are 4 boxes to be used in defense of liberty.
> Soap, ballot, jury, and ammo.
> Please use in that order, starting now. -Ed Howdershelt, Author
> Additions to this message made by Gene Heskett are Copyright 2004,
> Maurice E. Heskett, all rights reserved.
>
> _______________________________________________
> xorg mailing list
> xorg@freedesktop.org
> http://freedesktop.org/mailman/listinfo/xorg
>
From ufz6 at rz.uni-karlsruhe.de Sat Jul 3 16:44:07 2004
From: ufz6 at rz.uni-karlsruhe.de (Amir Bukhari)
Date: Sat Jul 3 16:41:18 2004
Subject: [Xorg] Understanding Xserver?
Message-ID: <E1Bgu8B-0002Bw-00@mailgate.rz.uni-karlsruhe.de>

I have started a project on Xserver. I should make some study and
modification on it (to run java display manager with 3D effect). Therefore I
need to understand it as well.
What did you advise me to start with? I know it is a big project, but it is
possible to understand it.

I have not used before Xlib directly.
Surely I do not need to change something in driver section and I also want
not change on original code as possible as I can. It will be better if I
make my modification as modules.

Therefore I need information like where Events are defined and the whole X
protocol .etc.
Thanks
Amir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://freedesktop.org/pipermail/xorg/attachments/20040704/eabfe5dd/attachm
ent.htm
From eta at lclark.edu Sat Jul 3 17:59:08 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sat Jul 3 17:59:42 2004
In-Reply-To: <2d429e9d0407030903704be9d4@mail.gmail.com>
References: <2d429e9d0407030903704be9d4@mail.gmail.com>
Message-ID: <1088902748.75873.0.camel@leguin>
On Sat, 2004-07-03 at 09:03, Hagbard Celine wrote:
> Hi,
>
> I'm trying to compile fdo xserver.
> Using the script xserver-inst.sh everything goes well and the Xvesa
> starts with few and weird colors but starts. Proud of this success I
> tryed to compile the xserver with dri (ok) and glx (problems) enabled.
The GLX code that was checked in was a WIP. Notably it doesn't work
with composite (I don't think) so there's not too much utility in it
yet. It definitely doesn't work with DRI.
--
Eric Anholt eta@lclark.edu
http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
From eger at havoc.gtf.org Sat Jul 3 19:13:16 2004
From: eger at havoc.gtf.org (David Eger)
Date: Sat Jul 3 19:13:50 2004
Subject: [Xorg] Re: [Linux-fbdev-devel] [PATCH] radeonfb: mode switch work
around
In-Reply-To: <200407040900.41880.adaplas@hotpop.com>
References: <200406301047.57423.adaplas@hotpop.com>
<20040704000518.GA14801@havoc.gtf.org>
<20040704004627.GA17768@havoc.gtf.org>
<200407040900.41880.adaplas@hotpop.com>
Message-ID: <20040704021316.GA23914@havoc.gtf.org>
On Sun, Jul 04, 2004 at 09:00:41AM +0800, Antonino A. Daplas wrote:
> On Sunday 04 July 2004 08:46, David Eger wrote:
> >
> > > Here's the fix for radeonfb for use with your patch.
> >
> > On second look, strike that. I have general badness trying to
> > switch out of X in recent kernels to radeonfb. Grr.. I'm not
> > having luck pinpointing what went wrong just yet.
>
> Maybe your hardware is one that requires a set_par() in both fbcon_blank()
> and fbcon_switch(), the worst case scenario....? If that's the case, we need
> another flag (and another ugyly workaround).
Actually, I'm trying older kernels that I'm sure didn't have this problem
(2.6.6) and I'm thinking instead the bad X->VT switch is due to the X.Org
code. I recently switched from XFree... hrmmm :-(
I hate to uninstall/reinstall X again just to test (I run gentoo... good god)
-Unhappy David
From jonsmirl at yahoo.com Sat Jul 3 19:59:23 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sat Jul 3 19:59:25 2004
around
In-Reply-To: <20040704021316.GA23914@havoc.gtf.org>
Message-ID: <20040704025923.39501.qmail@web14930.mail.yahoo.com>
I have noticed this too. I don't think it is specific to x.org. My best
guess is that the X server is mucking with the VGA registers on the
radeon card.
Try this experiment...
modprobe radeonfb from a VT, then switch to an xterm and rmmod it.
Try it the other way to, modprobe from xterm and rmmod from VT.
Both of those result in a reboot on my machine.
The problem seems to be with radeonfb snap shotting the register state
when it loads, and then restoring it when it unloads. But the VT/xterm
pair causes the retored registers to be set to the wrong values.
This saved register state is also used in other places. These other
uses may be the source of the problem you see. If I remember right, X
is also saving a snap shot of the initial register values.
--- David Eger <eger@havoc.gtf.org> wrote:
> On Sun, Jul 04, 2004 at 09:00:41AM +0800, Antonino A. Daplas wrote:
> > On Sunday 04 July 2004 08:46, David Eger wrote:
> > >
> > > > Here's the fix for radeonfb for use with your patch.
> > >
> > > On second look, strike that. I have general badness trying to
> > > switch out of X in recent kernels to radeonfb. Grr.. I'm not
> > > having luck pinpointing what went wrong just yet.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
From ufz6 at rz.uni-karlsruhe.de Sun Jul 4 02:05:02 2004
Date: Sun Jul 4 02:02:15 2004
Subject: [Xorg] Can not start server?
Message-ID: <1088931902.27587.14.camel@localhost>
I have compiled the source with xserver-inst.sh without errors. but I
receive this error:
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/c39:1
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Fatal server error:
Failed to establish all listening sockets
From eger at havoc.gtf.org Sun Jul 4 02:35:42 2004
Date: Sun Jul 4 02:37:19 2004
around
In-Reply-To: <Pine.GSO.4.58.0407041034250.21842@waterleaf.sonytel.be>
<Pine.GSO.4.58.0407041034250.21842@waterleaf.sonytel.be>
Nevermind the patch I sent. I tracked down my X->VT issue to
my xorg.conf file. It was missing the line
Option "UseFBDev"
Tony, your patch (the one with the big HACK ALERT sticker on it)
seems to give radeon the mode switch call when it is needed.
-dte
From eich at pdx.freedesktop.org Sun Jul 4 01:56:33 2004
Date: Sun Jul 4 07:55:28 2004
Subject: [Xorg] VSW4 test suite
In-Reply-To: anderson@netsweng.com wrote on Wednesday,
30 June 2004 at 11:39:48 -0400
References: <16608.15821.893814.352412@hermes.local>
<Pine.LNX.4.56.0406290518560.1976@localhost>
<16610.56341.297625.673232@xf11.fra.suse.de>
<Pine.LNX.4.56.0406301138000.1629@localhost>
Message-ID: <16615.50753.365204.964090@hermes.local>
Stuart Anderson writes:
> On Wed, 30 Jun 2004, Egbert Eich wrote:
>
> > Stuart,
> >
> > do you also have a pointer to the sources?
> > I would like to check them into the CVS and make available documentation
> > how to build them from scratch.
>
> It is in our CVS at http://www.gforge.freestandards.org.
>
> Does it make sense to make another copy of this code? We will be maintaining
> (and hopefully extending it). If there is not already a file in our source fo
r
> building it, we could easily add one.
>
I would thing that those who have access to the freedesktop CVS may also
be interested in having access to the test suite to do work on it.
The work done on it may not be immeditately suitable for inclusion into
the FSG standards, but I feel that giving people a low barrier to
work on the test suite - with the same CVS policies as we have for
the X.Org tree - may help to make more rapid progress on this.
We can always move snapshots from releases over to the FSG site.
Egbert.
Date: Sun Jul 4 07:55:28 2004
In-Reply-To: alan@lxorguk.ukuu.org.uk wrote on Friday,
2 July 2004 at 18:06:36 +0100
<16613.38281.414846.796738@xf11.fra.suse.de>
Alan Cox writes:
> On Gwe, 2004-07-02 at 18:04, Egbert Eich wrote:
> > Do you refer to config port access directly thru the 'well known' 'config
> > mechanism 1' (ie PIO 0xcf8 0xcfc registers), or do you mean access to
> > PCI config space from user space altogether - even when using the kernel
> > functions?
>
> Using conf1. Accessing via the kernel provided functions is fine
>
OK, sounds good.
We can change the default by changing one or two lines in the code.
The reason that we is conf1 instead of the kernel interface is that
I thought the latencies may be somewhat lower when using it for RAC.
On some platforms (like AXP) we always had to go thru the kernel.
Egbert.
Date: Sun Jul 4 07:56:12 2004
In-Reply-To: vektor@dumbterm.net wrote on Friday,
2 July 2004 at 16:55:37 -0500
References: <20040702215537.GA2880@dumbterm.net>
Billy Biggs writes:
> Hi,
>
> I am wondering if someone who is familiar with Xorg vs XFree86 in
> terms of XVIDEO could take a look at this bug:
>
>
> Basically, users of both the ATI binary drivers and the Matrox driver
> are complaining that XVIDEO applications can't be run until they shut
> down pixmap-eating apps like Mozilla. This problem does not seem to
> occur under XFree86 (or at least, not nearly as frequently). I hear a
> lot of complaints from FC2 users about this bug.
>
> Is there something that changed in how video memory is being
> allocated between the two X servers?
>
I assume that the changes in the offscreen memory manager produced this
problem. For video you need a rather large linear chunk of offscreen memory.
If I have time I'll take a look.
Cheers,
Egbert.
Date: Sun Jul 4 07:56:15 2004
In-Reply-To: erikharrison@gmail.com wrote on Friday,
2 July 2004 at 16:50:55 -0400
References: <5b18a542040702135027d7c04d@mail.gmail.com>
Erik Harrison writes:
> I was frustrated the other day by my seeming inability to learn C. As
> I actually speak Perl and was hoping for some distraction, is started
> to poke around in getconfig.pl.
>
> getconfig has a small list of PCI ID to driver mappings inside the
> program itself. Considering that we install a default xorg.cfg file,
> is it really sane to keep this information in getconfig? I could move
> it out into xorg.cfg if it's the Right Thing.
>
getconfig.pl was a project done by David Dawes on XFree86. The pieces that
were under the original (XFree86 1.0) license made it over into the X.Org
tree.
It is certainly not a good idea to maintain such a list in the program
itself. I assume it was just ment to be a temporary solution. Such a list
can be kept in a separate data file, however xorg.conf doesn't seem to
be the right place as it is used as a custom configuration file. Even
with automatic configuration around one must be able to create such a
custom file and that one would then most likely overwrite this data.
Any other file in /etc/X11 would be fine, I think.
Cheers,
Egbert.
Date: Sun Jul 4 07:56:15 2004
Subject: [Xorg] XINPUT additions; maybe add an XDEVICE extension?
In-Reply-To: krahn@niehs.nih.gov wrote on Friday,
2 July 2004 at 12:21:34 -0400
<16607.59124.921806.956671@hermes.local>
<40E15455.9060104@bitplanet.net>
<16613.25143.44541.395195@xf11.fra.suse.de>
<40E58B8E.1000509@niehs.nih.gov>
Joe Krahn writes:
> A lot of XINPUT commands are written as if they were made as
> interfaces to X extensions in general. For example, XINPUT
> defines XSelectExtensionEvent(), which is (I think) the only
> standard interface to non-hardwired extension event types.
> Also, many input devices are really output devices as well,
> even in XINPUT which defines output as Feedback events.
Worse even though they pretend to be more general they are really
XInput specific. It looks to me as if someone tried to add more
generic interfaces but for a lack of space to put them they were
stuck into XInput.
These things really should go into XFixes instead.
>
> IMHO, XINPUT should really be XDEVICE. But, XINPUT is
> already well established. So, perhaps a development plan
> could be to add a new extension called XDEVICE that
> does all of the device managament and configuration, and
> could be designed not just for input devices, but for any
> device.
In this case the client needs to be able to figure out which
XDEVICE device matches which XINPUT device. This seems to be
trivial however it isn't as XINPUT devices are much more generic
than XDEVICE devices will be.
>
> Regardless, XINPUT itself still needs some updating.
>
Definitely.
Egbert.
Date: Sun Jul 4 07:56:22 2004
In-Reply-To: keithp@keithp.com wrote on Friday, 2 July 2004 at 13:51:12 -0400
References: <16613.36927.224614.633810@xf11.fra.suse.de>
<E1BgSBu-0006Va-LW@evo.keithp.com>
>
> Around 18 o'clock on Jul 2, Egbert Eich wrote:
>
> > We have never been able to support multiple ISA video cards.
> > However RAC is an importand issue for a lot of PCI (AGP) graphics cards
> > at least during initialization.
>
> Ok; I didn't understand the limits of ISA card access; having
> (fortunately) never used a computer with an ISA video card...
>
> And, of course we need some way to touch the VGA I/O ports on arbitrary
> video cards (I believe some S3 cards must be poked in I/O ports before
> they enable MMIO register access).
Not only S3 cards. Some others also. In fact the ISA support is only
100-200 lines of code on top of the general mechanism to ensure correct
routing of VGA resources.
>
> > It is not only Intel that creates these problems. For many brand new video
> > cards the VESA driver is the only option.
>
> Right; you can either use the VESA X driver or the VESA fbdev kernel
> driver. I mostly wanted to note that even "vendor" drivers can rely on
> the BIOS for mode selection, which is pretty harsh.
Right, when I saw this I felt sorry that I've ever done the int10 stuff :-/
It was ment to be a fallback solution. Now vendors have discovered it
as a feature.
>
> > We should not need any PCI remapping if the kernel itself does the right
> > mapping.
>
> I thought the problem was that sometimes the kernel can't know what address
> range is needed by an arbitrary card -- motherboard and video card bugs
> sometimes mean that only a subset of the video memory ends up getting
> mapped by the time the X server starts. Without some way to ask the kernel
> to remap things, it wouldn't be possible to fix this safely from user-mode.
The only problem of that kind I'm aware of was with an old S3 card
made by ELSA in the very early days of PCI. In order to extend the
video memory beyond the chip limits the board manufacturer added
some extra logic to board. With this the size of this memory range
as advertised by PCI config space was no longer valid.
If you want to know more you'd have to ask Harald Koenig who wrote
support for this driver for XFree86 3.x.
I made considerable effords to be able to deal with cases like this
in the resource manager code of XFree86 4.x - however the driver had
never been ported.
Sometimes however there is need for drivers to override the generic
default settings made by the kernel: For example the 2.6 kernel seems
to add WC to any prefetchable PCI memory range. This is how it should be.
However some Silicon Motion chips seem to have a HW bug that causes
the chip to lock up when setting the last 4K if video ram (just below
the MMIO ranges) WC.
I've never had a chance to do some deeper investigation of this problem
as I never saw it myself.
>
> > What we may need is an IOCTL to set VGA routing on bridges.
>
> I'd sure rather see the X server not need to understand the whole PCI bus
> layout...
>
No, from an X point if view this is entirely irrelevant. From a hardware
driver layer this will be relevant on OSes that don't handle these things
thru the kernel.
I would think 85-90 percent of the users can be served well without it.
The other 10-15 percent are users of older versions of Linux and users
of other less popular OSes.
We can either go and tell theese to go get lost and seek support
elsewhere or we can add some reasonable fallback support for OSes
that don't provide these features.
Egbert.

Date: Sun Jul 4 07:56:27 2004
In-Reply-To: daniel@freedesktop.org wrote on Thursday,
1 July 2004 at 13:24:46 +1000
<20040629151608.GB21053@fooishbar.org>
<20040701032446.GU21053@fooishbar.org>
Daniel Stone writes:
> Of course you do - loginfo,v is 775. You don't edit the file directly,
> you do cvs co CVSROOT from :ext:cvs.freedesktop.org:/cvs/mesa. You edit
> loginfo there, and check it in. You'll also need to update checkoutlist.
>
> > I think that whoever updated the CVS software should have updated the
> > scripts too.
>
> I updated cvs, to 1:1.12.9-1.1. Before that, it was myself who updated to
> 1:1.12.8-1.1, and 1:1.12.3-1.1. These were all security releases, and
> there's something like eight compromises fixed.
>
> I have no desire to maintain a forked copy of CVS (with old-style info
> parsing) - having to apply a patch to shut pserver up on read-only mode
> so clients don't get confused is bad enough.
>
> I applied it to fix security issues; I do not know how to update the
> info scripts (I know *how* to do so, but I don't know what to change it
> to). Thus, I have no intention of doing so.
>
> There are 324 repositories across 55 projects. My time spent on admin
> stuff is already stretched beyond what I'd hope it would be; there's no
> way I'm going through and updating all the CVS trees.
I think every project should have its own maintainer for the CVS control
files. I was doing this for X.Org in the past and I would continue doing
it. However I was not aware at all that cvs was updated nor that the
control files needed attention.
>
> I know it sucks, and when I found out, I wanted to punch the physical
> representation of CVS in the head. There's a reason I use tla for most
> everything these days.
>
Yes, I think these people have gone over the top. CVS doesn't appear to
be the solid, backward compatible app it used to be.
On the other hand, has version 12 been declared stable at all? I've seen
a lot of problems with a previous sub-version of version 12 which even
produced repository corruption which needed to be fixed by hand.
Furthermore it would quit on me in the middle of a larger operation.
That's why I've installed cvs version 11 for my own personal use.
Egbert.
Date: Sun Jul 4 07:56:27 2004
<E1BgSGZ-0006W9-Hw@evo.keithp.com>
>
>
> > My conclusion was that one should move the entire device and
> > chipset probing (currently Probe() and PreInit() in the X drivers)
> > to an external deamon. This would also take care of the access control
> > among different Xserver instances.
>
> Would you also consider moving the mode configuration logic to this
> daemon? With that in place, the mode selection would no longer be tied to
> the X server itself so that other systems could take advantage of it.
> I'm particularily interested in getting mesa-solo running for some cards.
>
Right. That's what is ultimately going to happen.
I'm thinking about starting a project for that. I just need to get
a few pieces together. A lot of code is presently in the Xserver that
can be used as a model for the functionalities needed.
Egbert.
Date: Sun Jul 4 07:56:30 2004
<E1BgSRf-0006Z6-JQ@evo.keithp.com>
>
>
> > It depends on if you want to implement different system specific mechanisms
> > into the clients by adding them to the toolkits or if you want to abstract
> > away things from the clients (and the toolkits) by putting the system
> > dependent functionality into one central place (the Xserver) which exposes
> > a uniform interface to its clients.
>
> These aren't incompatible; the common interface for clients remain the X
> input extension.
Right.
>
> How the X server discovers available devices and collects data for and
> about them will remain somewhat system dependent. The suggestion here is to
> modify how the X server learns about devices; currently it's "magic", and
> so desktop software has no standard way to fix or change the behaviour.
Right. Currently we are discussing two strategies:
1. Let the Xserver sit directly on top of the hw drivers and let it handle
the system dependent pieces.
2. put the system dependent pieces into an independent process and create
a unified protocol for communication between the Xserver and this process.
I was talking about something else:
The Xclients will need to do device aquisition and configuration beyond
the capabilities of what the XInput extension can do today.
As I understood you you wanted to expose the interface for this to the
client in a system dependent way bypassing X.
>
> We can either have the X server provide some new standard protocol for
> applications to configure the set of devices the X server should use, or
> we can just use the X protocol for that purpose. Either is functionaly
> equivalent, I think both present similar security "challenges". I think
> using the X protocol will be somewhat easier to implement and will
> trivially provide network transparency for this configuration.
OK, that makes sense. If you suggest a standardized (ie. system independent)
protocol for device configuration we are on the same page.
For the transport it makes sense to use the already existing X protocol.
>
> That's just my first opinion though; it wouldn't take a lot of data to
> force this to be reevaluated...
>
True.
Egbert.
Date: Sun Jul 4 07:56:31 2004
In-Reply-To: krh@bitplanet.net wrote on Saturday,
3 July 2004 at 17:52:24 +0200
<16608.14200.939504.532986@hermes.local>
<16613.36429.355137.54150@xf11.fra.suse.de>
<40E6D638.7060501@bitplanet.net>
> Egbert Eich wrote:
> > Kristian H?gsberg writes:
> > > The main idea behind keeping the discovery mechanism out of the server
> > > was that different systems can use different mechanisms. On GNOME or
> > > KDE desktops I think it would make good sense to use HAL for detection
> > > (which is generic and system-wide), but an embedded system may well want

> > > to use something more lean.
> >
> > It depends on if you want to implement different system specific mechanisms
> > into the clients by adding them to the toolkits or if you want to abstract
> > away things from the clients (and the toolkits) by putting the system
> > dependent functionality into one central place (the Xserver) which exposes
> > a uniform interface to its clients.
>
> It wasn't my intention that all clients should use the hotplug requests,
> only the input device hotplug daemon. Toolkit support should not be
> necessary either, you would use the XInput Xlib API directly. This way
> you still have system dependent functionality in one central place, it's
> just not in the X server but in the hotplug daemon.
>
OK, we are already talking about such a 'daemon' for programming output
devices. I guess it would make some sense to have one daemon for input
and another one for output.
What I worry about a little bit is an extra support burdeon as we have
to run start three processes to get X up and running. If due to some
misconfiguration or misinstallation one of them isn't working we have
a support nightmare. Something along the line of
" My KDE/Gnome doesn't start ....
...
... Cannot find font 'fixed'"
> ...
>
> > What I remember right now:
> > 1.a. Clearify meaning of device type and device name in the XDeviceInfo
> > struct. Type is an Atom form a fixed list.
> > b. A device type touchpad is meaningless as it doesn't describe what
> > device (stylus, eraser, mouse etc.) is attached.
>
> Yeah, this bit from xf86Xinput.c:xf86ActivateDevice() doesn't help:
>
> local->atom = MakeAtom(local->name,
> strlen(local->name),
> TRUE);
> AssignTypeAndName (dev, local->atom, local->name);
Right. This is completely broken. I've started to make a fix however havn't
checked all drivers yet.
>
> i.e. it creates a atom for the device name and uses it as the type :-/.
> Here's output from a modified xsetpointer -l:
>
> "Mouse0" XID=3, type=Mouse0 (115) [XPointer]
> "keyboard" XID=4, type=NULL (0) [XKeyboard]
> "stylus" XID=2, type=stylus (114) [XExtensionDevice]
> "eraser" XID=1, type=eraser (113) [XExtensionDevice]
> "cursor" XID=0, type=cursor (112) [XExtensionDevice]
>
> > 2. Make device controls more flexible. A device control currently
> > is an XID. Make it an Atom.
>
> Can this be done in a backward compatible way or would we need a new
> request? Btw, why is the device control both in the
> XChangeDeviceControl() argument list and in the XDeviceControl struct?
> That's redundant...
You mean the control type? Yes, that's what I've wondered, too.
It needs to be in the struct so you know how to interpret the remaining
parts of the struct. That it is passed as an argument may be a leftover
from some preliminary design that had been placed out in the wilde already
when it was discovered that it should really exist in the struct. So it
was kept for backward compatibility. (just speculating).
Cheers,
Egbert.
From daniel at freedesktop.org Sun Jul 4 08:11:39 2004
Date: Sun Jul 4 08:11:43 2004
In-Reply-To: <16615.51478.377169.28818@hermes.local>
<20040629151608.GB21053@fooishbar.org>
<20040701032446.GU21053@fooishbar.org>
<16615.51478.377169.28818@hermes.local>
Message-ID: <20040704151139.GW4379@fooishbar.org>
On Sun, Jul 04, 2004 at 11:08:38AM +0200, Egbert Eich wrote:
> Yes, I think these people have gone over the top. CVS doesn't appear to
> be the solid, backward compatible app it used to be.
> On the other hand, has version 12 been declared stable at all? I've seen
> a lot of problems with a previous sub-version of version 12 which even
> produced repository corruption which needed to be fixed by hand.
> Furthermore it would quit on me in the middle of a larger operation.
> That's why I've installed cvs version 11 for my own personal use.
I don't know - I just see the vulnerabilities roll in in
+debian-security-announce or other, pull anoncvs down, get the new source
and apply my patch, install the package, and it's done.
Personally, CVS is uninteresting for me. I use it when I need to, but
for personal stuff, I don't even consider it.
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040705/83e5a8a1/attach
ment.pgp
Date: Sun Jul 4 08:12:49 2004
<16615.62516.639748.384714@hermes.local>
Message-ID: <20040704151247.GX4379@fooishbar.org>
On Sun, Jul 04, 2004 at 02:12:36PM +0200, Egbert Eich wrote:
> Erik Harrison writes:
> > I was frustrated the other day by my seeming inability to learn C. As
> > I actually speak Perl and was hoping for some distraction, is started
> > to poke around in getconfig.pl.
> >
> > getconfig has a small list of PCI ID to driver mappings inside the
> > program itself. Considering that we install a default xorg.cfg file,
> > is it really sane to keep this information in getconfig? I could move
> > it out into xorg.cfg if it's the Right Thing.
> >
>
> getconfig.pl was a project done by David Dawes on XFree86. The pieces that
> were under the original (XFree86 1.0) license made it over into the X.Org
> tree.
Last I checked, the whole thing was under the X-Oz licence, which was
the same as XFree86 1.1.
> It is certainly not a good idea to maintain such a list in the program
> itself. I assume it was just ment to be a temporary solution. Such a list
> can be kept in a separate data file, however xorg.conf doesn't seem to
> be the right place as it is used as a custom configuration file. Even
> with automatic configuration around one must be able to create such a
> custom file and that one would then most likely overwrite this data.
> Any other file in /etc/X11 would be fine, I think.
This is what /usr/share is for - static data files.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040705/19421d78/attach
ment.pgp
From jonsmirl at yahoo.com Sun Jul 4 08:46:03 2004
Date: Sun Jul 4 08:46:06 2004
--- Egbert Eich <eich@pdx.freedesktop.org> wrote:
> > > What we may need is an IOCTL to set VGA routing on bridges.
> >
> > I'd sure rather see the X server not need to understand the whole
> > PCI bus layout...
> >
>
> No, from an X point if view this is entirely irrelevant. From a
> hardware driver layer this will be relevant on OSes that don't
> handle these things thru the kernel.
>
> I would think 85-90 percent of the users can be served well without
> it. The other 10-15 percent are users of older versions of Linux
> and users of other less popular OSes.
>
> We can either go and tell theese to go get lost and seek support
> elsewhere or we can add some reasonable fallback support for OSes
> that don't provide these features.
>
Or we can just push hardware support like this to an external library.
On Linux 2.6 this library will be tiny since most things are handled by
the OS. On other platforms the library may be much larger. Resetting
secondary cards is also something that should be handled externally
since X is not the only client for these.
A good place to start would be to extract the existing code from X and
convert it to a standalone library. I have tried doing this twice but
the existing code is very, very intertwined into the X server. Both
times I have given up because I got tired of fixing hundreds of
dependencies between the library and the X server.
Building this library would determine the API that is needed. Once the
API is settled we can build a Linux 2.6 version that has all of the
redundant code removed.

=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
From alan at lxorguk.ukuu.org.uk Sun Jul 4 08:18:52 2004
Date: Sun Jul 4 09:21:49 2004
<16613.38281.414846.796738@xf11.fra.suse.de>
<16615.61334.485236.834278@hermes.local>
On Sul, 2004-07-04 at 12:52, Egbert Eich wrote:
> We can change the default by changing one or two lines in the code.
> The reason that we is conf1 instead of the kernel interface is that
> I thought the latencies may be somewhat lower when using it for RAC.
The latency probably is. There is also a real risk that during your
conf sequence someone else will come along and do other conf operations
(off an IRQ or another processor) however.
From keithp at keithp.com Sun Jul 4 10:24:27 2004
Date: Sun Jul 4 10:24:43 2004
In-Reply-To: Your message of "Sun, 04 Jul 2004 13:25:37 +0200."
<16615.59697.92405.178099@hermes.local>
Message-ID: <E1BhAj5-0001Td-V2@evo.keithp.com>
> Right. That's what is ultimately going to happen.
> I'm thinking about starting a project for that. I just need to get
> a few pieces together. A lot of code is presently in the Xserver that
> can be used as a model for the functionalities needed.
Cool. There are lots of people with a minor interest in having this
happen, but no-one currently motivated to actually start writing the code.
My idea is that by providing a standard API we could let people who want
to do this kind of thing in the kernel do just that while leaving those
devices which need user-mode code to prepare video modes with access to
that capability.
Hooking this up to the existing Linux hotplug system would grant even
kernel fbdev drivers access to this logic.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040704/80c5e6e0/attach
ment.pgp
Date: Sun Jul 4 10:27:15 2004
<16616.2005.906730.871468@hermes.local>
Message-ID: <E1BhAlV-0001Ty-NQ@evo.keithp.com>
> What I worry about a little bit is an extra support burdeon as we have
> to run start three processes to get X up and running. If due to some
> misconfiguration or misinstallation one of them isn't working we have
> a support nightmare.
That's a very good point; we often forget that system configuration
complexity leads directly to system mis-configuration. The system should
either be impossible to mis-configure, or should be designed to
self-correct in the face of error. The first is clearly better.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040704/330b0ce2/attach
ment.pgp
Date: Sun Jul 4 10:31:33 2004
<16616.2880.954088.811317@hermes.local>
Message-ID: <E1BhApi-0001Uy-3U@evo.keithp.com>
> The Xclients will need to do device aquisition and configuration beyond
> the capabilities of what the XInput extension can do today.
> As I understood you you wanted to expose the interface for this to the
> client in a system dependent way bypassing X.
No, I didn't want to suggest this. For input devices closely associated
with the window system, we'll need to find a way to manipulate them
through the X input extension.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040704/3a5ee5dc/attach
ment.pgp
From eta at lclark.edu Sun Jul 4 13:35:46 2004
Date: Sun Jul 4 13:36:20 2004
Subject: [Xorg] Re: CVS Update: xc (branch: trunk)
In-Reply-To: <E1BfKAz-00024N-3l@pdx.freedesktop.org>
References: <E1BfKAz-00024N-3l@pdx.freedesktop.org>
On Tue, 2004-06-29 at 08:05, Roland Mainz wrote:
> CVSROOT: /cvs/xorg
> Module name: xc
> Changes by: gisburn@pdx. 04/06/29 08:05:37
>
> Log message:
> Fix for freedesktop.org/bugzilla/show_bug.cgi?id=805 - Build fix for Linux/A
MD64
>
> Modified files:
> ./:
> ChangeLog
> xc/extras/Mesa/src/mesa/main/:
> imports.h
Please, please, please do not commit to xc/extras/Mesa unless it's
something that xorg requires to be done there that can't be merged
upstream. Changes to bring files off the vendor branch will lead to
more and more pain when trying to merge DRI bits.
The proper solution with CVS to get the change into Mesa, check out the
vendor branch, and commit the same change on the vendor branch (or just
arrange to do a whole new import at the time). If you don't want to do
that yourself, please bugzilla and assign to me.
--
From eger at havoc.gtf.org Sun Jul 4 14:06:43 2004
Date: Sun Jul 4 14:07:22 2004
Subject: [Xorg] xkb and macintosh
My question for you all:
Does anyone use the macintosh keymaps in X(.org|Free86)?
I have a Powerbook running a recent linux kernel (2.6.x series).
I tried to set my keyboard to the intuitively obvious settings:
Option "XkbRules" "xorg"
Option "XkbModel" "powerbook"
Option "XkbLayout" "en_US"
Option "XkbVariant" "nodeadkeys"
Option "XkbOptions" ""
And I got some strange results:
+ Pressing Alt+a key gives me accented characters
+ Trying to press Alt-x (for M-x in emacs) from an xterm sent M-8
to emacs.
+ Standard Backspace vs Delete problem.
PPC/linux standardized on 'linux keycodes' that sorta look like
a PC keyboard with the extra keys, so when I set the settings
back to:
Option "XkbModel" "pc104"
Option "XkbLayout" "us"
Option "XkbVariant" ""
Option "XkbOptions" ""
things work fine. (Though I'm still trying to grok how I can make
my Open Apple key compose those nice accented characters...)
-dte
From elylevy-xserver at cs.huji.ac.il Sun Jul 4 16:49:41 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Sun Jul 4 16:49:45 2004
Subject: [Xorg] small compile fix for xkbfile
Message-ID: <Pine.LNX.4.56.0407050248001.28904@grok.cs.huji.ac.il>
it makes xkbfile compile on my computer
but maybe someone add a reason for doing it this way
Ely Levy
System group
Hebrew University
Jerusalem Israel
-------------- next part --------------
Index: configure.ac
===================================================================
RCS file: /cvs/xlibs/xkbfile/configure.ac,v
retrieving revision 1.2
diff -u -r1.2 configure.ac
--- configure.ac 25 Jun 2004 12:55:36 -0000 1.2
+++ configure.ac 4 Jul 2004 23:47:33 -0000
@@ -24,7 +24,7 @@
AC_MSG_ERROR([The path $xkb_base does not denote the directory])
fi

-X_CFLAGS="$X_CFLAGS -DDFLT_XKB_CONFIG_ROOT=\\\\\\\"$xkb_base\\\\\\\""
+X_CFLAGS="$X_CFLAGS -DDFLT_XKB_CONFIG_ROOT=\\\"$xkb_base\\\""

AC_SUBST(X_CFLAGS)
AC_SUBST(X_LIBS)
From loc at toya.net.pl Sun Jul 4 17:03:16 2004
Date: Sun Jul 4 17:03:21 2004
In-Reply-To: <Pine.LNX.4.56.0407050248001.28904@grok.cs.huji.ac.il>
References: <Pine.LNX.4.56.0407050248001.28904@grok.cs.huji.ac.il>
Message-ID: <40E89AC4.7070700@toya.net.pl>
Ely Levy wrote:
> it makes xkbfile compile on my computer
> but maybe someone add a reason for doing it this way
It's a mistake probably. I had to change it because it broke build on my
machine too.
--
Regards,
Jakub Piotr C?apa
Date: Sun Jul 4 17:12:41 2004
Subject: [Xorg] debuging Xserver
Message-ID: <E1BhH65-0004N5-00@mailgate.rz.uni-karlsruhe.de>
How is it the best way to debug Xserver?
Is there a way to write to file a debug information, like (entering a
function and exit from a function), so that when it crash I know
Where it has been crashed.
I will need such mechanism to debug the server.
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040705/a9377d59/attachm
ent.html
Date: Sun Jul 4 17:22:03 2004
In-Reply-To: <E1BhH65-0004N5-00@mailgate.rz.uni-karlsruhe.de>
References: <E1BhH65-0004N5-00@mailgate.rz.uni-karlsruhe.de>
Message-ID: <40E89F28.1060203@toya.net.pl>
Amir Bukhari wrote:
> How is it the best way to debug Xserver?
>
> Is there a way to write to file a debug information, like (entering a
> function and exit from a function), so that when it crash I know
>
> Where it has been crashed.
>
> I will need such mechanism to debug the server.
The best way is probably a gdb (gnu debugger) via serial console or ssh.
Try googling for some info on how to use it.
--
Regards,
Jakub Piotr C?apa
Date: Sun Jul 4 18:50:54 2004
Message-ID: <20040705015052.GZ4379@fooishbar.org>
On Mon, Jul 05, 2004 at 02:49:41AM +0300, Ely Levy wrote:
> it makes xkbfile compile on my computer
> but maybe someone add a reason for doing it this way
Um, yeah. I forgot to commit that fix. I'll do it now.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040705/be962eb4/attach
ment.pgp
From erikharrison at gmail.com Sun Jul 4 22:55:24 2004
Date: Sun Jul 4 22:55:57 2004
<16615.62516.639748.384714@hermes.local>
Message-ID: <5b18a542040704225555f086b5@mail.gmail.com>
On Sun, 4 Jul 2004 14:12:36 +0200, Egbert Eich <eich@pdx.freedesktop.org> wrote:
>
>
> Erik Harrison writes:
> > I was frustrated the other day by my seeming inability to learn C. As
> > I actually speak Perl and was hoping for some distraction, is started
> > to poke around in getconfig.pl.
> >
> > getconfig has a small list of PCI ID to driver mappings inside the
> > program itself. Considering that we install a default xorg.cfg file,
> > is it really sane to keep this information in getconfig? I could move
> > it out into xorg.cfg if it's the Right Thing.
> >
>
> getconfig.pl was a project done by David Dawes on XFree86. The pieces that
> were under the original (XFree86 1.0) license made it over into the X.Org
> tree.
> It is certainly not a good idea to maintain such a list in the program
> itself. I assume it was just ment to be a temporary solution. Such a list
> can be kept in a separate data file, however xorg.conf doesn't seem to
> be the right place as it is used as a custom configuration file. Even
> with automatic configuration around one must be able to create such a
> custom file and that one would then most likely overwrite this data.
> Any other file in /etc/X11 would be fine, I think.
I was actually referring to xorg.cfg. getconfig.pl looks in several
directories and concatenates all the *.cfg files it finds there to
build up it's initial set of rules. X.org currently installs a default
xorg.cfg (where I don't recall) which is at the moment empty.
>From what I remember about kudzu I think that Redhat has a database of
PCI IDs -> X drivers. The info in getconfig is pretty basic, I'll try
to pull out the Redhat database and combine it with the data in
getconfig - unless this information already exists somewhere? Is there
a record of what PCI IDs a driver works with?
>
> Cheers,
> Egbert.
>
From eich at pdx.freedesktop.org Mon Jul 5 04:30:31 2004
Date: Mon Jul 5 04:31:37 2004
In-Reply-To: keithp@keithp.com wrote on Sunday, 4 July 2004 at 10:26:57 -0700
<E1BhAlV-0001Ty-NQ@evo.keithp.com>
>
>
> > What I worry about a little bit is an extra support burdeon as we have
> > to run start three processes to get X up and running. If due to some
> > misconfiguration or misinstallation one of them isn't working we have
> > a support nightmare.
>
> That's a very good point; we often forget that system configuration
> complexity leads directly to system mis-configuration. The system should
> either be impossible to mis-configure, or should be designed to
> self-correct in the face of error. The first is clearly better.
>
True. What I'm also concerned about are crashes in the separate components
that happen in states of the system which rarely occur.
With X consisting of several subsystems the bug reports we receive from
users may be even less conclusive. (And we may have 3 log files instead of
one).
Egbert.
Date: Mon Jul 5 05:57:15 2004
In-Reply-To: daniel@freedesktop.org wrote on Monday,
5 July 2004 at 01:12:47 +1000
<16615.62516.639748.384714@hermes.local>
<20040704151247.GX4379@fooishbar.org>
>
> Last I checked, the whole thing was under the X-Oz licence, which was
> the same as XFree86 1.1.
The license in the pieces that are in the X.Org code are under the original
1.0 license terms. The newer pieces which are not in the X.Org code are under
the 1.1 license.
>
> > It is certainly not a good idea to maintain such a list in the program
> > itself. I assume it was just ment to be a temporary solution. Such a list
> > can be kept in a separate data file, however xorg.conf doesn't seem to
> > be the right place as it is used as a custom configuration file. Even
> > with automatic configuration around one must be able to create such a
> > custom file and that one would then most likely overwrite this data.
> > Any other file in /etc/X11 would be fine, I think.
>
> This is what /usr/share is for - static data files.
>
It depends how static these really are. /etc contains a lot of conf
files with blacklist data and other things one could argue to be static
also. This data file seems to be alnong that line.
Egbert.
Date: Mon Jul 5 06:22:56 2004
In-Reply-To: alan@lxorguk.ukuu.org.uk wrote on Sunday,
4 July 2004 at 16:18:52 +0100
<16613.38281.414846.796738@xf11.fra.suse.de>
<16615.61334.485236.834278@hermes.local>
Alan Cox writes:
> On Sul, 2004-07-04 at 12:52, Egbert Eich wrote:
> > We can change the default by changing one or two lines in the code.
> > The reason that we is conf1 instead of the kernel interface is that
> > I thought the latencies may be somewhat lower when using it for RAC.
>
> The latency probably is. There is also a real risk that during your
> conf sequence someone else will come along and do other conf operations
> (off an IRQ or another processor) however.
>
Yes, I realize this ;-) Therefore it needs to be fixed.
I'll commit a patch which will change the default behavior to use the
OS provided method if one is available.
One can still override this using an option - if this person finds the
correct option name.
Egbert.
Date: Mon Jul 5 06:29:09 2004
<E1BhAj5-0001Td-V2@evo.keithp.com>
>
>
> Cool. There are lots of people with a minor interest in having this
> happen, but no-one currently motivated to actually start writing the code.
>
> My idea is that by providing a standard API we could let people who want
> to do this kind of thing in the kernel do just that while leaving those
> devices which need user-mode code to prepare video modes with access to
> that capability.
We could probalby stick a large amount of this into the kernel and
make 85 to 90 percent of the users happy.
The reason why I don't advocate this but instead suggest to try to do as
much as possible from user land is that I don't want to make the other
10 to 15 percent unhappy by giving them the finger.
Furthermore it seems to be much harder to port things between kernels
of different OSes than to port a userland application to the interfaces
of a new kernel.
>
> Hooking this up to the existing Linux hotplug system would grant even
> kernel fbdev drivers access to this logic.
>
Let's keep this in mind.
Egbert.
From loc at toya.net.pl Mon Jul 5 07:48:03 2004
Date: Mon Jul 5 07:48:15 2004
References: <5b18a542040702135027d7c04d@mail.gmail.com> <16615.62516.639748.3847
14@hermes.local> <20040704151247.GX4379@fooishbar.org>
<16617.20454.396156.676528@hermes.local>
Message-ID: <40E96A23.3040002@toya.net.pl>
Egbert Eich wrote:
> Daniel Stone writes:
> > > It is certainly not a good idea to maintain such a list in the program
> > > itself. I assume it was just ment to be a temporary solution. Such a list
> > > can be kept in a separate data file, however xorg.conf doesn't seem to
> > > be the right place as it is used as a custom configuration file. Even
> > > with automatic configuration around one must be able to create such a
> > > custom file and that one would then most likely overwrite this data.
> > > Any other file in /etc/X11 would be fine, I think.
> >
> > This is what /usr/share is for - static data files.
>
> It depends how static these really are. /etc contains a lot of conf
> files with blacklist data and other things one could argue to be static
> also. This data file seems to be alnong that line.
/etc for configuration
/usr/share for static data (arch independent!)
/usr/lib for arch dependent static data
So /usr/share IMHO.
--
Regards,
Jakub Piotr C?apa
Date: Mon Jul 5 08:12:12 2004
In-Reply-To: ufz6@rz.uni-karlsruhe.de wrote on Monday,
5 July 2004 at 02:15:20 +0200
References: <E1BhH65-0004N5-00@mailgate.rz.uni-karlsruhe.de>
Amir Bukhari writes:
> How is it the best way to debug Xserver?
>
> Is there a way to write to file a debug information, like (entering a
> function and exit from a function), so that when it crash I know
>
> Where it has been crashed.
>
> I will need such mechanism to debug the server.
>
Please have a look at:
http://freedesktop.org/XOrg/DebuggingTheXserver
Cheers,
Egbert.
PS: Would you please disable HTML in your emails? Thanks!
Date: Mon Jul 5 08:22:12 2004
In-Reply-To: erikharrison@gmail.com wrote on Monday,
5 July 2004 at 01:55:24 -0400
<16615.62516.639748.384714@hermes.local>
<5b18a542040704225555f086b5@mail.gmail.com>
Erik Harrison writes:
>
> I was actually referring to xorg.cfg. getconfig.pl looks in several
> directories and concatenates all the *.cfg files it finds there to
> build up it's initial set of rules. X.org currently installs a default
> xorg.cfg (where I don't recall) which is at the moment empty.
I was confusing this with xorg.conf, the name of the default configuration
file. However this shows that the name xorg.cfg can be confusing. Instead
a name which explains the use of the file would be preferrable.
>
> >From what I remember about kudzu I think that Redhat has a database of
> PCI IDs -> X drivers. The info in getconfig is pretty basic, I'll try
> to pull out the Redhat database and combine it with the data in
> getconfig - unless this information already exists somewhere? Is there
> a record of what PCI IDs a driver works with?
Every distro has this. Usually this information is contained in the drivers.
Normally one would load all drivers and have them probe which chipset is
present. I thought that's what getconfig.pl is doing, too - using the *cfg
files only for overrides (ie chipsets that are not yet listed in a
driver but working when specifying a similar older chipset).
Egbert.
From alan at lxorguk.ukuu.org.uk Mon Jul 5 08:10:00 2004
Date: Mon Jul 5 09:12:53 2004
In-Reply-To: <40E96A23.3040002@toya.net.pl>
<16615.62516.639748.384714@hermes.local>
<20040704151247.GX4379@fooishbar.org>
<16617.20454.396156.676528@hermes.local> <40E96A23.3040002@toya.net.pl>
On Llu, 2004-07-05 at 15:48, Jakub Piotr C?apa wrote:
> /etc for configuration
> /usr/share for static data (arch independent!)
> /usr/lib for arch dependent static data
>
> So /usr/share IMHO.
That would agree with the Linux file system standard (unless you are
starting X before mounting /usr of course which some folks do)
From daniel at freedesktop.org Mon Jul 5 09:15:07 2004
Date: Mon Jul 5 09:15:09 2004
In-Reply-To: <1089040199.431.0.camel@localhost.localdomain>
<16615.62516.639748.384714@hermes.local>
<20040704151247.GX4379@fooishbar.org>
<16617.20454.396156.676528@hermes.local>
<40E96A23.3040002@toya.net.pl>
Message-ID: <20040705161507.GI4379@fooishbar.org>
On Mon, Jul 05, 2004 at 04:10:00PM +0100, Alan Cox wrote:
> On Llu, 2004-07-05 at 15:48, Jakub Piotr C??apa wrote:
> > /etc for configuration
> > /usr/share for static data (arch independent!)
> > /usr/lib for arch dependent static data
> >
> > So /usr/share IMHO.
>
> That would agree with the Linux file system standard (unless you are
> starting X before mounting /usr of course which some folks do)
... in which case the standard of /usr and the usually-used-yet-really-stupid
/usr/X11R6 aren't mounted.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/8f48cf09/attach
ment.pgp
From jonsmirl at yahoo.com Mon Jul 5 09:27:51 2004
Date: Mon Jul 5 09:27:56 2004
> We could probalby stick a large amount of this into the kernel and
> make 85 to 90 percent of the users happy.
> The reason why I don't advocate this but instead suggest to try to do
> as
> much as possible from user land is that I don't want to make the
> other
> 10 to 15 percent unhappy by giving them the finger.
> Furthermore it seems to be much harder to port things between kernels
> of different OSes than to port a userland application to the
> interfaces
> of a new kernel.
But now we end up building everything twice on Linux since fbdev needs
all of these things too. Then we have to spend time making the X and
fbdev versions play nice together. Plus, X's PCI bus manipulations are
in direct conflict with the Linux kernel.
Why not build an external library that adds these features to the OS's
that don't have them and uses the OS routines when available. This
library would be small on Linux and big on BSD. The library interface X
uses would be the same on both OS's. Mesa-solo needs this same library.
Another example of this is sorting out where hotplug input devices go
in a multiuser system. Linux is going to have to do this at the
kernel/library level in order to support framebuffer console. This code
can easily sort these things out for X too. But if X builds a system
for this too then we have to make everything coordinate and use the
same config files, etc.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Date: Mon Jul 5 09:49:35 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Sunday, 4 July 2004 at 08:46:03 -0700
<20040704154603.49752.qmail@web14927.mail.yahoo.com>
Jon Smirl writes:
> --- Egbert Eich <eich@pdx.freedesktop.org> wrote:
> >
> > No, from an X point if view this is entirely irrelevant. From a
> > hardware driver layer this will be relevant on OSes that don't
> > handle these things thru the kernel.
> >
> > I would think 85-90 percent of the users can be served well without
> > it. The other 10-15 percent are users of older versions of Linux
> > and users of other less popular OSes.
> >
> > We can either go and tell theese to go get lost and seek support
> > elsewhere or we can add some reasonable fallback support for OSes
> > that don't provide these features.
> >
>
> Or we can just push hardware support like this to an external library.
> On Linux 2.6 this library will be tiny since most things are handled by
> the OS. On other platforms the library may be much larger. Resetting
> secondary cards is also something that should be handled externally
> since X is not the only client for these.
Actually I'm currently thinking of an external daemon for such things
as some things are stateful and we need to be able to preserve states
accross applications.
>
> A good place to start would be to extract the existing code from X and
> convert it to a standalone library. I have tried doing this twice but
> the existing code is very, very intertwined into the X server. Both
> times I have given up because I got tired of fixing hundreds of
> dependencies between the library and the X server.
Right. Since I wrote a lot of this stuff I might be the right person to
do this. Actually I have plans to do this ASAP.
>
> Building this library would determine the API that is needed. Once the
> API is settled we can build a Linux 2.6 version that has all of the
> redundant code removed.
>
Right. I'll do my best ;-) However I expect I will not arrive at the
complete solution the first time around.
Cheers,
Egbert.
Date: Mon Jul 5 09:50:45 2004
<E1BhApi-0001Uy-3U@evo.keithp.com>
>
>
> > The Xclients will need to do device aquisition and configuration beyond
> > the capabilities of what the XInput extension can do today.
> > As I understood you you wanted to expose the interface for this to the
> > client in a system dependent way bypassing X.
>
> No, I didn't want to suggest this. For input devices closely associated
> with the window system, we'll need to find a way to manipulate them
> through the X input extension.
OK.
Sorry for the misunderstanding. Looks like we are pretty much on the
same page ;-)
Cheers,
Egbert.
Date: Mon Jul 5 10:21:26 2004
In-Reply-To: krh@bitplanet.net wrote on Saturday,
3 July 2004 at 17:52:24 +0200
<16608.14200.939504.532986@hermes.local>
<16613.36429.355137.54150@xf11.fra.suse.de>
<40E6D638.7060501@bitplanet.net>
...
>
> It wasn't my intention that all clients should use the hotplug requests,
> only the input device hotplug daemon. Toolkit support should not be
> necessary either, you would use the XInput Xlib API directly. This way
> you still have system dependent functionality in one central place, it's
> just not in the X server but in the hotplug daemon.
>
OK.
> ...
>
> > What I remember right now:
> > 1.a. Clearify meaning of device type and device name in the XDeviceInfo
> > struct. Type is an Atom form a fixed list.
> > b. A device type touchpad is meaningless as it doesn't describe what
> > device (stylus, eraser, mouse etc.) is attached.
>
> Yeah, this bit from xf86Xinput.c:xf86ActivateDevice() doesn't help:
>
> local->atom = MakeAtom(local->name,
> strlen(local->name),
> TRUE);
> AssignTypeAndName (dev, local->atom, local->name);
>
> i.e. it creates a atom for the device name and uses it as the type :-/.
Yes, that is completely bogus.
> Here's output from a modified xsetpointer -l:
>
> "Mouse0" XID=3, type=Mouse0 (115) [XPointer]
> "keyboard" XID=4, type=NULL (0) [XKeyboard]
> "stylus" XID=2, type=stylus (114) [XExtensionDevice]
> "eraser" XID=1, type=eraser (113) [XExtensionDevice]
> "cursor" XID=0, type=cursor (112) [XExtensionDevice]
>
> > 2. Make device controls more flexible. A device control currently
> > is an XID. Make it an Atom.
>
> Can this be done in a backward compatible way or would we need a new
> request? Btw, why is the device control both in the
> XChangeDeviceControl() argument list and in the XDeviceControl struct?
> That's redundant...
>
control is an XID in the XDeviceControl structure which is pretty much
an unsigned long. This would match an Atom which is also an unsigned
long. However in XGetDeviceControl() and XChangeDeviceControl() it is
an int :-/ On the wire its a 32bit container. This would not create
problems.
Egbert.
From nicolas at boichat.ch Mon Jul 5 14:49:28 2004
From: nicolas at boichat.ch (Nicolas Boichat)
Date: Mon Jul 5 14:39:46 2004
Subject: [Xorg] DDC/CI, need advice on implementation
Message-ID: <1089064168.11467.54.camel@bird>
Hello
I reverse-engineered a part of the DDC/CI protocol. This protocol is
used to control a monitor by software, without using the OSD.
I'll soon write some web pages explaining what I did to reverse-engineer
it, and on the protocol itself.
I modified the DDC driver
(xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.c), because it is the
easiest place to get access to the graphics card I2C bus (DDC2 and
DDC/CI are located on the same I2C bus), and I'm now able to read values
from my Mitsubishi Diamond Pro 2060u (I mean read contrast, brightness,
red, green and blue levels for example), but I still can't write values
(I don't think I'm very far).
Now I have a problem, I need to have access to the DDC/CI bus from an
external application, because, of course, I don't want to change the
monitor parameters only when the server loads.
I don't know much about XFree/Xorg, so I need your help:
- Should I create a new shared library in xc/lib? (for example
Xxf86ddcci)
- Or Should I add functions to an existing library ? (in this case,
which one? Xxf86vm? Xxf86misc?)
- Or should I do something else??
I would like to add in this library simple wrappers to functions that
are in I2C and DDC modules, is it possible and well designed ?
I hope I've been clear enough, if it is not the case please ask me.
Best regards,
Nicolas Boichat
Date: Mon Jul 5 14:54:35 2004
In-Reply-To: <1089064168.11467.54.camel@bird>
Does the fbdev driver for your card have a kernel level I2C driver? For
example matrox and radeon have this already. In that case you can load
the i2c-dev driver and control the bus from simple user space apps.
If not, it might be simpler to implement a kernel I2C driver for your
card than to mess around with the one in xfree. It is not hard to make
one, just look at the kernel driver for Matrox (mga) and the xfree
source code. That will provide everything you need to build your own.
--- Nicolas Boichat <nicolas@boichat.ch> wrote:
> Hello
>
> I reverse-engineered a part of the DDC/CI protocol. This protocol is
> used to control a monitor by software, without using the OSD.
>
> I'll soon write some web pages explaining what I did to
> reverse-engineer
> it, and on the protocol itself.
>
> I modified the DDC driver
> (xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.c), because it is the
> easiest place to get access to the graphics card I2C bus (DDC2 and
> DDC/CI are located on the same I2C bus), and I'm now able to read
> values
> from my Mitsubishi Diamond Pro 2060u (I mean read contrast,
> brightness,
> red, green and blue levels for example), but I still can't write
> values
> (I don't think I'm very far).
>
> Now I have a problem, I need to have access to the DDC/CI bus from an
> external application, because, of course, I don't want to change the
> monitor parameters only when the server loads.
>
> I don't know much about XFree/Xorg, so I need your help:
> - Should I create a new shared library in xc/lib? (for example
> Xxf86ddcci)
> - Or Should I add functions to an existing library ? (in this case,
> which one? Xxf86vm? Xxf86misc?)
> - Or should I do something else??
>
> I would like to add in this library simple wrappers to functions that
> are in I2C and DDC modules, is it possible and well designed ?
>
> I hope I've been clear enough, if it is not the case please ask me.
>
> Best regards,
>
> Nicolas Boichat
>
>
> _______________________________________________
> xorg mailing list
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From breun at xs4all.nl Mon Jul 5 15:00:55 2004
Date: Mon Jul 5 15:01:00 2004
In-Reply-To: <40E76277.70504@winischhofer.net>
References: <40E6C0D9.4000807@xs4all.nl> <40E6EEA5.1060501@winischhofer.net>
<15623.213.84.39.175.1088894126.squirrel@webmail.xs4all.nl>
<40E76277.70504@winischhofer.net>
Message-ID: <40E9CF97.8080301@xs4all.nl>
Thomas Winischhofer wrote:
>>> The SiS 6326 does not support 32 bpp (32 bit framebuffer depth).
>>
>> Apparently, but the nvidia driver also doesn't seem to support 24. Just a
>> bad combination of videocards then?
>
> I find it strange that you encounter this problem at all. Are you trying
> to run "Xinerama" or the "normal" kind of dual-head where each screen
> gets an X session of its own?
>
> If the latter, I would think that the pixmap depth should not matter at
> all; the screens are entirely independent. With Xinerama, however, the
> screens must be in sync wrt color depth, framebuffer depth and some
> other criteria.
>
> Please let me know if my current driver fixes your problem.
I haven't had the time to try your driver yet, but I would like to
respond to the statement above. I currently have a 'normal' kind of
dual-head setup (as can be seen from the xorg.conf I attached to my
original post). If the pixmap should not matter at all, then how should
I set it up? Can I specify a separate pixmap depth for each card/driver?
Now it's just a server-wide flag I'm setting.
Thanks,
Nils.
--
From krh at bitplanet.net Mon Jul 5 16:37:04 2004
Date: Mon Jul 5 16:38:36 2004
Subject: [Xorg] Keyboard drivers: kbd vs. keyboard
Message-ID: <40E9E620.3030900@bitplanet.net>
Hi,
I was looking at the keyboard driver situation, and I was wondering why
we keep the legacy, built-in keyboard driver around,
I made a patch[1] to remove the "keyboard" driver, which among other
things removes os specific xf86KbdLnx.c and others from xfree86/common,
removes all sorts special cases around initialization, and in general
removes much keyboard logic from xfree86/common and 4300 lines in total.
I chose to rename the modular "kbd" driver to "keyboard" so old config
files should continue to work.
I think this is worthwhile, but what are the cons? It's such a
low-hanging fruit; there must be a good reason the legacy driver is
still used.
Kristian
[1] http://freedesktop.org/~krh/remove-legacy-keyboard.patch
From keithp at keithp.com Mon Jul 5 17:29:19 2004
Date: Mon Jul 5 17:29:31 2004
In-Reply-To: Your message of "Tue, 06 Jul 2004 00:00:55 +0200."
<40E9CF97.8080301@xs4all.nl>
Message-ID: <E1Bhdpn-0001uq-Jj@evo.keithp.com>
> Thomas Winischhofer wrote:
> If the latter, I would think that the pixmap depth should not matter at
> all; the screens are entirely independent. With Xinerama, however, the
> screens must be in sync wrt color depth, framebuffer depth and some
> other criteria.
Alas, this is one place where the X server has some cross-screen
dependencies. X provides only one list of Z image formats for the entire
X server, as such two screens which expose different formats for the same
depth cannot be mixed.
This is a bit confusing to me though; the X server can "hide" the fact
that a screen is 24bpp and instead offer 32bpp Z-format images; this works
around numerous bugs in applications which can't deal with the odd 24bpp
format. At first blush, I would have guessed that with the server doing
this there wouldn't be any trouble with screens using different internal
formats as long as the exposed image format was the same. That can
probably be fixed if it is indeed a problem.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040705/be47f4f4/attach
ment.pgp
Date: Mon Jul 5 17:37:40 2004
In-Reply-To: Your message of "Mon, 05 Jul 2004 15:28:03 +0200."
<16617.22371.859445.768739@hermes.local>
Message-ID: <E1Bhdxj-0001vh-8X@evo.keithp.com>
> We could probalby stick a large amount of this into the kernel and make 85
> to 90 percent of the users happy. The reason why I don't advocate this but
> instead suggest to try to do as much as possible from user land is that I
> don't want to make the other 10 to 15 percent unhappy by giving them the
> finger.
My position here is to avoid taking a position -- migrate the existing mode
selection logic behind a new API and get the X server running on top of
that. This shouldn't cause any portability regressions, and will offer
individual driver authors the opportunity to experiment with different
user/kernel partitions without forcing everyone to choose a single
architecture.
Given that some cards will (always?) require user-mode support, we'll have
to provide all of the necessary hooks to grant kernel mode drivers access
to this logic, so there's no benefit in pushing anyone to migrate right
away.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040705/7ad60fc3/attach
ment.pgp
From thomas at winischhofer.net Mon Jul 5 17:45:51 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Mon Jul 5 17:47:34 2004
In-Reply-To: <E1Bhdpn-0001uq-Jj@evo.keithp.com>
References: <E1Bhdpn-0001uq-Jj@evo.keithp.com>
Message-ID: <40E9F63F.8010107@winischhofer.net>
Keith Packard wrote:
>>Thomas Winischhofer wrote:
>
>
>>If the latter, I would think that the pixmap depth should not matter at
>>all; the screens are entirely independent. With Xinerama, however, the
>>screens must be in sync wrt color depth, framebuffer depth and some
>>other criteria.
>
>
> Alas, this is one place where the X server has some cross-screen
> dependencies. X provides only one list of Z image formats for the entire
> X server, as such two screens which expose different formats for the same
> depth cannot be mixed.
I think Nils' problem boils down to the fact that I, a while back,
removed the "Convert24To32..." flags from fb init and put them back
immediately after a user of a SiS6326 reported problems with an older
application. Seems this short period was exactly when the X.org tree was
forked from XFree86 and 6.7.0 was released.
> This is a bit confusing to me though; the X server can "hide" the fact
> that a screen is 24bpp and instead offer 32bpp Z-format images; this works
> around numerous bugs in applications which can't deal with the odd 24bpp
> format. At first blush, I would have guessed that with the server doing
> this there wouldn't be any trouble with screens using different internal
> formats as long as the exposed image format was the same. That can
> probably be fixed if it is indeed a problem.
I am curiously awaiting his results with the current driver.
(However, the "nv" driver doesn't set these flags either. If the sis
driver works with these flags set and both settings for the Pixmap "24"
and "32", I'd say it's about time to fix the nv driver to do the same.)
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
Date: Mon Jul 5 17:54:28 2004
<40E9F63F.8010107@winischhofer.net>
Message-ID: <E1BheDq-0001zA-Id@evo.keithp.com>
Around 2 o'clock on Jul 6, Thomas Winischhofer wrote:
> I think Nils' problem boils down to the fact that I, a while back,
> removed the "Convert24To32..." flags from fb init and put them back
> immediately after a user of a SiS6326 reported problems with an older
> application.
Ah, now things are a lot more clear.
We await testing with the modified driver.
> (However, the "nv" driver doesn't set these flags either. If the sis
> driver works with these flags set and both settings for the Pixmap "24"
> and "32", I'd say it's about time to fix the nv driver to do the same.)
Does the 'nv' driver *ever* use 24bpp mode? If not, then it wouldn't
matter what flags were set.
-ketih
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040705/50679065/attach
ment.pgp
From gene.heskett at verizon.net Mon Jul 5 18:57:10 2004
Date: Mon Jul 5 18:57:13 2004
In-Reply-To: <40E9CF97.8080301@xs4all.nl>
References: <40E6C0D9.4000807@xs4all.nl> <40E76277.70504@winischhofer.net>
<40E9CF97.8080301@xs4all.nl>
On Monday 05 July 2004 18:00, Nils Breunese wrote:
>Thomas Winischhofer wrote:
>>>> The SiS 6326 does not support 32 bpp (32 bit framebuffer depth).
I am not seeing Thomas's posts coming in from the list, whats up with
this?
But, the above statement brought me up a bit short in that I have a
sis6326 chipset on an old Diamond SpeedStar A50 card that claims to
have 8 megs of ram, but the only limit I've seen is several folks
have posted that it can only access 4 megs of it from that chipset.
But to me, it appears that it supports 32bit inputs just fine, hence
the surprise at seeing that statement. This BTW, has absolutely
nothing to do with nvidia, also mentioned in this thread.
Nevertheless, here is a snip of a piece of xdpyinfo from that machine:
name of display: localhost:10.0
version number: 11.0
vendor string: The XFree86 Project, Inc
vendor release number: 40300000
XFree86 version: 4.3.0
maximum request size: 4194300 bytes
motion buffer size: 256
bitmap unit, bit order, padding: 32, LSBFirst, 32
image byte order: LSBFirst
number of supported pixmap formats: 7
supported pixmap formats:
depth 1, bits_per_pixel 1, scanline_pad 32
[... to some actual settings]
screen #0:
dimensions: 1600x1200 pixels (542x406 millimeters)
resolution: 75x75 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x8e
depth of root window: 24 planes
number of colormaps: minimum 1, maximum 1
default colormap: 0x20
default number of colormap cells: 256
preallocated pixels: black 0, white 16777215
options: backing-store NO, save-unders NO
largest cursor: 64x64
[...]
So it appears to be acknowledgeing a 32 bit setting, but running with
24, this on a 1600x1200 screen. In any event, there is no difference
in color reproduction between that machine and this one, which has a
gforce2 mx200, 32meg card in it. Noticeable diff in speed, but thats
only a 500mhz AMD K6-III too, where this is a 1600mhz athlon.
Gimp runs just fine for photo editing and printing but I have to
import the pix from this box as that old TYAN S1590 has a badly
broken set of usb chips on it. Its my firewall anyway.
>>> Apparently, but the nvidia driver also doesn't seem to support
>>> 24. Just a bad combination of videocards then?
>>
>> I find it strange that you encounter this problem at all. Are you
>> trying to run "Xinerama" or the "normal" kind of dual-head where
>> each screen gets an X session of its own?
>>
>> If the latter, I would think that the pixmap depth should not
>> matter at all; the screens are entirely independent. With
>> Xinerama, however, the screens must be in sync wrt color depth,
>> framebuffer depth and some other criteria.
>>
>> Please let me know if my current driver fixes your problem.
>
>I haven't had the time to try your driver yet, but I would like to
>respond to the statement above. I currently have a 'normal' kind of
>dual-head setup (as can be seen from the xorg.conf I attached to my
>original post). If the pixmap should not matter at all, then how
> should I set it up? Can I specify a separate pixmap depth for each
> card/driver? Now it's just a server-wide flag I'm setting.
>
>Thanks,
>
>Nils.
--
Cheers, Gene
Date: Mon Jul 5 19:04:19 2004
Subject: [Xorg] What is this fbdev I keep seeing mentioned?
See subject. Is this part of the x.org release?
I cannot find such a frame buffer device in the kernel .config for
2.6.7-mm6, nor any of the earlier 2.6.7-ish kernels I have here.
Could this be the reason my fresh nvidia 6106 install is stumbling
along at 75fps for glxgears?
--
Cheers, Gene
Date: Mon Jul 5 19:18:00 2004
In-Reply-To: <E1Bhdxj-0001vh-8X@evo.keithp.com>
--- Keith Packard <keithp@keithp.com> wrote:
> My position here is to avoid taking a position -- migrate the
> existing mode selection logic behind a new API and get the X server
There is a lot more to this. Some of the areas include:
Device detection
Reset, with real mode helper, getting the ROM contents
Active VGA device control, making sure there is only one
Locating device resources, where are registers/RAM, etc
Mode setting - for all heads
Who owns the hardware - root or user
Hotplug add/remove of video cards
Hotplug add/remove of input devices
Multiuser - what video/keyboard/mouse form a group, how do things get
assigned.
How can the kernel put up error messages on the display -- OOPS, printk
Coordination of VRAM memory management
This list is pretty large and I've probably forgotten a few things.
All of this matters equally to fbdev and X.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From alexdeucher at gmail.com Mon Jul 5 21:12:09 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Mon Jul 5 21:12:33 2004
Subject: [Xorg] What is this fbdev I keep seeing mentioned?
Message-ID: <a728f9f904070521124e3a3c7e@mail.gmail.com>
On Mon, 5 Jul 2004 22:04:15 -0400, Gene Heskett
<gene.heskett@verizon.net> wrote:
> See subject. Is this part of the x.org release?
>
> I cannot find such a frame buffer device in the kernel .config for
> 2.6.7-mm6, nor any of the earlier 2.6.7-ish kernels I have here.
fbdev refers to the linux framebuffer device. Kernel framebuffer
devices are chipset drivers that live in kernel space rather than user
space like Xorg drivers. Some Xorg drivers support a special mode
where the kernel framebuffer handles the mode setting and the Xorg
driver handles everything else. there's also a fbdev Xorg driver that
runs ontop of a kernel framebuffer driver. kernel framebuffer drivers
are either generic like vesa or vga, or chipset specific like mga or
radeon.
>
> Could this be the reason my fresh nvidia 6106 install is stumbling
> along at 75fps for glxgears?
The nvidia drivers may sync to the monitor refresh rate since that is
the default for OpenGL. There's probably an option somewhere to turn
off sync to refresh.
>
> --
> Cheers, Gene
> There are 4 boxes to be used in defense of liberty.
> Soap, ballot, jury, and ammo.
> Please use in that order, starting now. -Ed Howdershelt, Author
> Additions to this message made by Gene Heskett are Copyright 2004,
> Maurice E. Heskett, all rights reserved.
From thomas at winischhofer.net Tue Jul 6 00:47:59 2004
Date: Tue Jul 6 00:50:17 2004
References: <40E6C0D9.4000807@xs4all.nl>
<40E76277.70504@winischhofer.net> <40E9CF97.8080301@xs4all.nl>
<200407052157.10040.gene.heskett@verizon.net>
Message-ID: <40EA592F.9010106@winischhofer.net>
Gene Heskett wrote:
> On Monday 05 July 2004 18:00, Nils Breunese wrote:
>
>>Thomas Winischhofer wrote:
>>
>>>>>The SiS 6326 does not support 32 bpp (32 bit framebuffer depth).
>
>
> I am not seeing Thomas's posts coming in from the list, whats up with
> this?
*me stupid* still can't get used to "Reply All". Sorry.
> But, the above statement brought me up a bit short in that I have a
> sis6326 chipset on an old Diamond SpeedStar A50 card that claims to
> have 8 megs of ram, but the only limit I've seen is several folks
> have posted that it can only access 4 megs of it from that chipset.
That is true. God knows what the other 4 megs were for. (Probably
textures since I believe the 3D engine has one more address bit)
>
> But to me, it appears that it supports 32bit inputs just fine, hence
> the surprise at seeing that statement. This BTW, has absolutely
> nothing to do with nvidia, also mentioned in this thread.
Well, the original poster had a problem with a SiS6326 and some NVidia
card at the same time in the same box. So I suppose it actually does...
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
Date: Tue Jul 6 01:16:11 2004
References: <40E6C0D9.4000807@xs4all.nl>
<40EA592F.9010106@winischhofer.net>
Message-ID: <40EA5F44.7090200@winischhofer.net>
Gene Heskett wrote:
> On Tuesday 06 July 2004 03:47, Thomas Winischhofer wrote:
>>
>>*me stupid* still can't get used to "Reply All". Sorry.
Erm... your posting didn't make it to the list either ;)
>>That is true. God knows what the other 4 megs were for. (Probably
>>textures since I believe the 3D engine has one more address bit)
>
>
> What 3d engine, that cards an el-cheepo even when new.
Nevertheless, it has a 3D engine.
> But then I
> haven't seen 3d out of this nvidia card either, so I wouldn't know
> '3d' if it bit me on the ankle. :)
I suppose on any somewhat modern box, the CPU does the rendering way
faster than this SiS card from 1997 anyway.
> I see. I have one of each, but they are both agp cards, and in
> seperate boxes. I he was trying to make xinerama work, I'd imagine
> he would need similar cards, in pci slots probably.
You don't need "similar" cards, and they don't have to be both PCI
either. Works with any card regardless whether PCI, AGP or whatever
(except probably ISA).
Thomas
--
Thomas Winischhofer
Vienna/Austria
From breun at xs4all.nl Tue Jul 6 02:15:13 2004
Date: Tue Jul 6 02:15:16 2004
In-Reply-To: <40E9F63F.8010107@winischhofer.net>
References: <E1Bhdpn-0001uq-Jj@evo.keithp.com>
<40E9F63F.8010107@winischhofer.net>
Message-ID: <40EA6DA1.9050404@xs4all.nl>
> Keith Packard wrote:
>
>>> Thomas Winischhofer wrote:
>>
>> This is a bit confusing to me though; the X server can "hide" the fact
>> that a screen is 24bpp and instead offer 32bpp Z-format images; this
>> works around numerous bugs in applications which can't deal with the
>> odd 24bpp format. At first blush, I would have guessed that with the
>> server doing this there wouldn't be any trouble with screens using
>> different internal formats as long as the exposed image format was the
>> same. That can probably be fixed if it is indeed a problem.
>
>
> I am curiously awaiting his results with the current driver.
I just commented out the Pixmap Option in my xorg.conf to let X
determine the pixmap depth values itself. Judging from Xorg.0.log it
sets 24 for the SiS card and 32 for the nvidia one. But X won't start.
(**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
[...]
(**) SIS(1): Depth 24, (--) framebuffer bpp 24
[...]
Fatal server error:
Inconsistent depth 24 pixmap format. Exiting
This is not a Xinerama setup, so why does the server complain about
inconsistent depth 24 pixmap format? I thought it did not matter when
not in Xinerama mode?
Then again, you're talking about trying the 'current driver'. I guess
maybe that's not the one I got on my system. I just got the latest
testing rpm of xorg-x11 for Fedora 2 on my system. I never actually
looked into CVS and compiling my own stuff. This is the version I have:
(II) SIS(1): SiS driver (2004/02/26-1)
(II) SIS(1): Copyright (C) 2001-2004 Thomas Winischhofer
<thomas@winischhofer.net> and others
(II) SIS(1): Compiled for X.Org 4.3.99.902
> (However, the "nv" driver doesn't set these flags either. If the sis
> driver works with these flags set and both settings for the Pixmap "24"
> and "32", I'd say it's about time to fix the nv driver to do the same.)
On my system the sus driver only works when set to 24, but that you say
is proabably fixed in the 'current version'? Indeed the nv driver
doesn't work when set to 24. Also nvidia's own binary release doesn't
support setting it to 24.
Nils.
Attachment: Xorg.0.log with pixmap option commented out in xorg.conf.
--
-------------- next part --------------
Name: Xorg.0.log.tar.gz
Type: application/x-gzip
Size: 7208 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/d45c7d35/Xorg.0
.log.tar.bin
From nicolas at boichat.ch Tue Jul 6 02:35:07 2004
Date: Tue Jul 6 02:24:12 2004
Thanks for the idea, you're probably right.
I have a nVidia card so I'll work on a kernel driver.
Best regards,
Nicolas
Le lun 05/07/2004 ? 23:54, Jon Smirl a ?crit :
> Does the fbdev driver for your card have a kernel level I2C driver? For
> example matrox and radeon have this already. In that case you can load
> the i2c-dev driver and control the bus from simple user space apps.
>
> If not, it might be simpler to implement a kernel I2C driver for your
> card than to mess around with the one in xfree. It is not hard to make
> one, just look at the kernel driver for Matrox (mga) and the xfree
> source code. That will provide everything you need to build your own.
>
> --- Nicolas Boichat <nicolas@boichat.ch> wrote:
> > Hello
> >
> > I reverse-engineered a part of the DDC/CI protocol. This protocol is
> > used to control a monitor by software, without using the OSD.
> >
> > I'll soon write some web pages explaining what I did to
> > reverse-engineer
> > it, and on the protocol itself.
> >
> > I modified the DDC driver
> > (xc/programs/Xserver/hw/xfree86/ddc/xf86DDC.c), because it is the
> > easiest place to get access to the graphics card I2C bus (DDC2 and
> > DDC/CI are located on the same I2C bus), and I'm now able to read
> > values
> > from my Mitsubishi Diamond Pro 2060u (I mean read contrast,
> > brightness,
> > red, green and blue levels for example), but I still can't write
> > values
> > (I don't think I'm very far).
> >
> > Now I have a problem, I need to have access to the DDC/CI bus from an
> > external application, because, of course, I don't want to change the
> > monitor parameters only when the server loads.
> >
> > I don't know much about XFree/Xorg, so I need your help:
> > - Should I create a new shared library in xc/lib? (for example
> > Xxf86ddcci)
> > - Or Should I add functions to an existing library ? (in this case,
> > which one? Xxf86vm? Xxf86misc?)
> > - Or should I do something else??
> >
> > I would like to add in this library simple wrappers to functions that
> > are in I2C and DDC modules, is it possible and well designed ?
> >
> > I hope I've been clear enough, if it is not the case please ask me.
> >
> > Best regards,
> >
> > Nicolas Boichat
> >
> >
> > _______________________________________________
> > xorg mailing list
> > xorg@freedesktop.org
> > http://freedesktop.org/mailman/listinfo/xorg
> >
>
>
> =====
> Jon Smirl
> jonsmirl@yahoo.com
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
>
From eich at pdx.freedesktop.org Tue Jul 6 02:32:36 2004
Date: Tue Jul 6 02:33:43 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Monday, 5 July 2004 at 09:27:51 -0700
Jon Smirl writes:
> --- Egbert Eich <eich@pdx.freedesktop.org> wrote:
> > We could probalby stick a large amount of this into the kernel and
> > make 85 to 90 percent of the users happy.
> > The reason why I don't advocate this but instead suggest to try to do
> > as
> > much as possible from user land is that I don't want to make the
> > other
> > 10 to 15 percent unhappy by giving them the finger.
> > Furthermore it seems to be much harder to port things between kernels
> > of different OSes than to port a userland application to the
> > interfaces
> > of a new kernel.
>
> But now we end up building everything twice on Linux since fbdev needs
> all of these things too. Then we have to spend time making the X and
> fbdev versions play nice together. Plus, X's PCI bus manipulations are
> in direct conflict with the Linux kernel.
>
> Why not build an external library that adds these features to the OS's
> that don't have them and uses the OS routines when available. This
> library would be small on Linux and big on BSD. The library interface X
> uses would be the same on both OS's. Mesa-solo needs this same library.
I would like to arrive at a single driver source for all OSes.
video chipsets probably have more registers than any other hardware
- many of them serve obscure purposes and are poorly documented.
driver development - unlike a lot of other code - is not cheap.
No use that two groups have to go thru the same agony.
Most other things are not quite that critical. We can duplicate
the PCI and address space mapping stuff easily as this is doesn't
have to be redone for each chipset but is more platform and OS
depent.
> Another example of this is sorting out where hotplug input devices go
> in a multiuser system. Linux is going to have to do this at the
> kernel/library level in order to support framebuffer console. This code
> can easily sort these things out for X too. But if X builds a system
> for this too then we have to make everything coordinate and use the
> same config files, etc.
We have already discussed a daemon solution. Which parts would have to
live on the kernel level?
Egbert.
Date: Tue Jul 6 02:37:54 2004
In-Reply-To: <40EA6DA1.9050404@xs4all.nl>
References: <E1Bhdpn-0001uq-Jj@evo.keithp.com> <40E9F63F.8010107@winischhofer.n
et>
<40EA6DA1.9050404@xs4all.nl>
Message-ID: <40EA726B.8070002@winischhofer.net>
Nils Breunese wrote:
> I just commented out the Pixmap Option in my xorg.conf to let X
> determine the pixmap depth values itself. Judging from Xorg.0.log it
> sets 24 for the SiS card and 32 for the nvidia one. But X won't start.
>
> (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32
>
> [...]
>
> (**) SIS(1): Depth 24, (--) framebuffer bpp 24
>
> [...]
>
> Fatal server error:
> Inconsistent depth 24 pixmap format. Exiting
>
> This is not a Xinerama setup, so why does the server complain about
> inconsistent depth 24 pixmap format? I thought it did not matter when
> not in Xinerama mode?
Me too... I see Keith actually had a point ;)
> Then again, you're talking about trying the 'current driver'. I guess
> maybe that's not the one I got on my system.
As I said in my very first mail, I mean the driver from my website. You
could use CVS as well, but I have pre-compiled binaries saving you the
effort.
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Tue Jul 6 02:46:58 2004
In-Reply-To: krh@bitplanet.net wrote on Tuesday, 6 July 2004 at 01:37:04 +0200
References: <40E9E620.3030900@bitplanet.net>
The reason for keeping this driver around was I think that the
other driver doesn't support all OSes X supports.
Before we make such a change we need to make sure that we don't
deprive certain people of their keyboard.
Egbert.
> Hi,
>
> I was looking at the keyboard driver situation, and I was wondering why
> we keep the legacy, built-in keyboard driver around,
>
> I made a patch[1] to remove the "keyboard" driver, which among other
> things removes os specific xf86KbdLnx.c and others from xfree86/common,
> removes all sorts special cases around initialization, and in general
> removes much keyboard logic from xfree86/common and 4300 lines in total.
>
> I chose to rename the modular "kbd" driver to "keyboard" so old config
> files should continue to work.
>
> I think this is worthwhile, but what are the cons? It's such a
> low-hanging fruit; there must be a good reason the legacy driver is
> still used.
>
> Kristian
>
> [1] http://freedesktop.org/~krh/remove-legacy-keyboard.patch
>
> _______________________________________________
> xorg mailing list
From loc at toya.net.pl Tue Jul 6 02:51:44 2004
Date: Tue Jul 6 02:51:52 2004
References: <5b18a542040702135027d7c04d@mail.gmail.com> <16615.62516.639748.3847
14@hermes.local> <20040704151247.GX4379@fooishbar.org> <16617.20454.396
156.676528@hermes.local> <40E96A23.3040002@toya.net.pl>
<16618.27162.487671.325812@hermes.local>
Message-ID: <40EA7630.600@toya.net.pl>
Egbert Eich wrote:
> Jakub Piotr C$,1 b(Bapa writes:
> > >
> > > It depends how static these really are. /etc contains a lot of conf
> > > files with blacklist data and other things one could argue to be static
> > > also. This data file seems to be alnong that line.
> >
> >
>
> I doubt that this override data is all that static.
> Overrides may be necessary temporarily until support
> for a specific chipset is added.
But who will override? If distros, then it's ok to keep it in /usr/share.
/etc is not a playce for datafiles IMHO. On the other hand it isn't so
important - make it configurable and it won't be a problem. (distro
vendors will change it if they want).
--
Regards,
Jakub Piotr C?apa
From krh at bitplanet.net Tue Jul 6 03:17:44 2004
Date: Tue Jul 6 03:19:18 2004
<16618.29691.567223.832889@hermes.local>
Message-ID: <40EA7C48.1020105@bitplanet.net>
Yeah, I suspected as much. But isn't that a chicken-and-egg problem? If
the legacy driver continues to be supported, we'll never get the missing
bits done for the new driver. I really think it's worthwhile, and it
ties in nicely with the XInput cleanup/hotplug work.
What about marking the legacy driver as deprecated (print a big warning
if it is used) and encourage people to use the new driver. After a
while, maybe the release after the next, we remove the legacy driver.
Kristian
Egbert Eich wrote:
> The reason for keeping this driver around was I think that the
> other driver doesn't support all OSes X supports.
> Before we make such a change we need to make sure that we don't
> deprive certain people of their keyboard.
>
> Egbert.
>
>
> > Hi,
> >
> > I was looking at the keyboard driver situation, and I was wondering why
> > we keep the legacy, built-in keyboard driver around,
> >
> > I made a patch[1] to remove the "keyboard" driver, which among other
> > things removes os specific xf86KbdLnx.c and others from xfree86/common,
> > removes all sorts special cases around initialization, and in general
> > removes much keyboard logic from xfree86/common and 4300 lines in total.
> >
> > I chose to rename the modular "kbd" driver to "keyboard" so old config
> > files should continue to work.
> >
> > I think this is worthwhile, but what are the cons? It's such a
> > low-hanging fruit; there must be a good reason the legacy driver is
> > still used.
> >
> > Kristian
> >
> > [1] http://freedesktop.org/~krh/remove-legacy-keyboard.patch
> >
> > _______________________________________________
>
Date: Tue Jul 6 03:24:24 2004
References: <16617.22371.859445.768739@hermes.local> <20040705162752.37964.qm
ail@web14925.mail.yahoo.com>
<16618.29108.552996.705856@hermes.local>
Message-ID: <40EA7D52.1030903@winischhofer.net>
Egbert Eich wrote:
> Jon Smirl writes:
> > --- Egbert Eich <eich@pdx.freedesktop.org> wrote:
> > > We could probalby stick a large amount of this into the kernel and
> > > make 85 to 90 percent of the users happy.
> > > The reason why I don't advocate this but instead suggest to try to do
> > > as
> > > much as possible from user land is that I don't want to make the
> > > other
> > > 10 to 15 percent unhappy by giving them the finger.
> > > Furthermore it seems to be much harder to port things between kernels
> > > of different OSes than to port a userland application to the
> > > interfaces
> > > of a new kernel.
> >
> > But now we end up building everything twice on Linux since fbdev needs
> > all of these things too. Then we have to spend time making the X and
> > fbdev versions play nice together. Plus, X's PCI bus manipulations are
> > in direct conflict with the Linux kernel.
> >
> > Why not build an external library that adds these features to the OS's
> > that don't have them and uses the OS routines when available. This
> > library would be small on Linux and big on BSD. The library interface X
> > uses would be the same on both OS's. Mesa-solo needs this same library.
>
> I would like to arrive at a single driver source for all OSes.
> video chipsets probably have more registers than any other hardware
> - many of them serve obscure purposes and are poorly documented.
> driver development - unlike a lot of other code - is not cheap.
> No use that two groups have to go thru the same agony.
Well, in reality they don't have to. Looking at each others code has
been done, is being done and will be done anyway. A bit more of
cooperation between fbdev and X driver developers (if not identical)
would minimize this "agony" (if any). And finally: fbdev drivers are
really dumb pieces of software compared to a modern X driver. The only
thing they share is mode setup in general (internals differ, of course).
But before we talk about transferring video stuff - what level ever -
into the kernel (which I personally am not especially keen about) I
suggest we first agree on
- what hardware architectures and
- what OS platforms
we intend to support. (Couldn't find any official statement regarding
these qeustions anywhere on x.org at first glimpse.)
After these lists are complete, the next step would be to evaluate what
it takes to get stuff into the kernel on all these archs/platforms, how
long release cycles usually take, what the respective kernel maintainers
think about it (ie whether or not the would accept any of this) and so on.
From my experience, getting gfx stuff into the linux kernel sometimes
means smuggling it in behind Linus' back. An agony of its own kind if
one knows Linus' attitude to fbdev drivers and graphics stuff in the
kernel in general. No idea how other kernel maintainers like this idea,
not at least when it comes to non-OSS, commercial kernels.
My very humble $.02 as one who's been in X driver development and user
support for a mere 4 years: Forcing people to change and reconfigure
their kernel just to run the "current gui" is something I really can't
imagine being a much appreciated idea. And the "gui" shouldn't really be
able to take down the entire machine in case of a bug. Welcome to the
world of Windows (and debugging hell, besides).
I can well agree on moving resource allocation stuff into the kernel if
not there already; mode setup etc, however, I tend to think is userland
stuff. Not even speaking of 2D, video, HW cursor, color management, etc
(ie stuff that requires register access in the same way as mode setup).
Hell, I guess I am one of the "10 to 15 percent".
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Tue Jul 6 03:35:29 2004
In-Reply-To: <40EA7CDB.2000907@xs4all.nl>
References: <E1Bhdpn-0001uq-Jj@evo.keithp.com> <40E9F63F.8010107@winischhofer.n
et>
<40EA6DA1.9050404@xs4all.nl> <40EA726B.8070002@winischhofer.net>
<40EA7CDB.2000907@xs4all.nl>
Message-ID: <40EA7FEA.9010807@winischhofer.net>
Nils Breunese wrote:
> Thomas Winischhofer wrote:
>
>> Nils Breunese wrote:
>>
>>> Then again, you're talking about trying the 'current driver'. I guess
>>> maybe that's not the one I got on my system.
>>
>>
>> As I said in my very first mail, I mean the driver from my website.
>> You could use CVS as well, but I have pre-compiled binaries saving you
>> the effort.
>
>
> Thanks to your driver and the easy installation instructions my
> dual-head setup works again!
Good to know. Thanks. I guess I wasn't that wrong after all ;)
> If a future build of X.org will pop up in
> an apt-get upgrade session, will it have a sis driver supporting 24 for
> pixmap?
Of course. This has been fixed in CVS a pretty long time ago.
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Tue Jul 6 04:24:24 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Monday, 5 July 2004 at 19:17:57 -0700
References: <E1Bhdxj-0001vh-8X@evo.keithp.com>
Jon Smirl writes:
> --- Keith Packard <keithp@keithp.com> wrote:
> > My position here is to avoid taking a position -- migrate the
> > existing mode selection logic behind a new API and get the X server
>
> There is a lot more to this. Some of the areas include:
>
> Device detection
> Reset, with real mode helper, getting the ROM contents
> Active VGA device control, making sure there is only one
> Locating device resources, where are registers/RAM, etc
> Mode setting - for all heads
> Who owns the hardware - root or user
> Hotplug add/remove of video cards
> Hotplug add/remove of input devices
> Multiuser - what video/keyboard/mouse form a group, how do things get
> assigned.
> How can the kernel put up error messages on the display -- OOPS, printk
> Coordination of VRAM memory management
>
> This list is pretty large and I've probably forgotten a few things.
>
> All of this matters equally to fbdev and X.
>
If you consider fbdev as something that lives solely in the kernel
the only solution would be to place most - if not all - of the
functionality mentioned above into the kernel.
If we can agree on that all the kernel needs is a framebuffer
with certain properties (like location, size, depth ...)
most things listed above could also live in a userland daemon.
I acknowledge that there are still problems:
for the boot console the graphics chipset needs to be initialized
at boot time by the bootloader or kernel.
I'm still trying to figure out what systems require such initialization.
Certainly some embedded systems do - but there this may require some
custom solution anyway.
VRAM coordination for printk's is also tricky: on some chipsets you
need to know if the chipset is idle. If the kernel can still communicate
with the daemon process it can let this handle the output.
Egbert.
Date: Tue Jul 6 04:46:16 2004
In-Reply-To: keithp@keithp.com wrote on Monday, 5 July 2004 at 17:37:31 -0700
<E1Bhdxj-0001vh-8X@evo.keithp.com>
>
>
> > We could probalby stick a large amount of this into the kernel and make 85
> > to 90 percent of the users happy. The reason why I don't advocate this but
> > instead suggest to try to do as much as possible from user land is that I
> > don't want to make the other 10 to 15 percent unhappy by giving them the
> > finger.
>
> My position here is to avoid taking a position -- migrate the existing mode
> selection logic behind a new API and get the X server running on top of
> that. This shouldn't cause any portability regressions, and will offer
> individual driver authors the opportunity to experiment with different
> user/kernel partitions without forcing everyone to choose a single
> architecture.
When you are talking about kernel partition you tie yourself to a single
OS - not necessarily a single architecture. This is what worries me a little
bit.
Egbert.
Date: Tue Jul 6 04:50:11 2004
In-Reply-To: loc@toya.net.pl wrote on Monday, 5 July 2004 at 16:48:03 +0200
<16615.62516.639748.384714@hermes.local>
<20040704151247.GX4379@fooishbar.org>
<16617.20454.396156.676528@hermes.local>
<40E96A23.3040002@toya.net.pl>
Jakub Piotr C$,1 b(Bapa writes:
> >
> > It depends how static these really are. /etc contains a lot of conf
> > files with blacklist data and other things one could argue to be static
> > also. This data file seems to be alnong that line.
>
> /etc for configuration
> /usr/share for static data (arch independent!)
> /usr/lib for arch dependent static data
>
> So /usr/share IMHO.
I doubt that this override data is all that static.
Overrides may be necessary temporarily until support
for a specific chipset is added.
At least there should be a file in /etc/X11 to which the
admin can add entries as temporary workarounds.
Egbert.
From daniel at freedesktop.org Tue Jul 6 04:56:40 2004
Date: Tue Jul 6 04:56:42 2004
<16615.62516.639748.384714@hermes.local>
<20040704151247.GX4379@fooishbar.org>
<16617.20454.396156.676528@hermes.local>
<40E96A23.3040002@toya.net.pl>
<16618.37299.527796.712843@hermes.local>
Message-ID: <20040706115640.GR4379@fooishbar.org>
On Tue, Jul 06, 2004 at 01:49:07PM +0200, Egbert Eich wrote:
> Jakub Piotr C$,1 b(Bapa writes:
> > >
> > > It depends how static these really are. /etc contains a lot of conf
> > > files with blacklist data and other things one could argue to be static
> > > also. This data file seems to be alnong that line.
> >
> >
>
> I doubt that this override data is all that static.
> Overrides may be necessary temporarily until support
> for a specific chipset is added.
> At least there should be a file in /etc/X11 to which the
> admin can add entries as temporary workarounds.
Whyy not have an option in xorg.conf for the filename, and allow it to
be overridden there, and then place it in /usr/share per default?
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/be3ae771/attach
ment-0001.pgp
Date: Tue Jul 6 06:55:50 2004
In-Reply-To: krh@bitplanet.net wrote on Tuesday, 6 July 2004 at 12:17:44 +0200
<16618.29691.567223.832889@hermes.local>
<40EA7C48.1020105@bitplanet.net>
> Yeah, I suspected as much. But isn't that a chicken-and-egg problem? If
> the legacy driver continues to be supported, we'll never get the missing
> bits done for the new driver. I really think it's worthwhile, and it
> ties in nicely with the XInput cleanup/hotplug work.
>
> What about marking the legacy driver as deprecated (print a big warning
> if it is used) and encourage people to use the new driver. After a
> while, maybe the release after the next, we remove the legacy driver.
>
What you should do is to disable build by default and allow people
to enable it if they have to. This will be a gentle hint that OS
maintainers should take action.
It would be even better to declare it deprecated and set a date by
which it will go away, announce and discuss it on the mailing list
(here) and on the Wiki (should we have a developers announce?).
Unfortunately not every group that's interested in X is assembled
here (yet).
Cheers,
Egbert.
Date: Tue Jul 6 07:21:57 2004
In-Reply-To: thomas@winischhofer.net wrote on Tuesday,
6 July 2004 at 12:22:10 +0200
<16618.29108.552996.705856@hermes.local>
<40EA7D52.1030903@winischhofer.net>
Hi Thomas,
Thomas Winischhofer writes:
>
> Well, in reality they don't have to. Looking at each others code has
> been done, is being done and will be done anyway. A bit more of
> cooperation between fbdev and X driver developers (if not identical)
> would minimize this "agony" (if any). And finally: fbdev drivers are
There still is a little obstacle that is tied to the license of the
drivers. Kernel drivers are GPL. To use them as a sample to derive
code for an MIT Licensed driver one would have to go thru a 'clean
room' step.
> really dumb pieces of software compared to a modern X driver. The only
> thing they share is mode setup in general (internals differ, of course).
That may be true for the SiS driver. It is not necessarily true for
other drivers - especially ones that have been orphaned in X for a
while.
>From what I hear the MCA fbdev driver in the kernel has better support
for DVI than the X driver has.
Furthermore there are the little pesky problems I'm thinking about:
someone may find a fix and add it to one driver. The maintainer of the
other driver may not even realize the fix.
>
> But before we talk about transferring video stuff - what level ever -
> into the kernel (which I personally am not especially keen about) I
> suggest we first agree on
>
> - what hardware architectures and
> - what OS platforms
>
> we intend to support. (Couldn't find any official statement regarding
> these qeustions anywhere on x.org at first glimpse.)
Presently we support OSes for which there is no representative on
this list, yet. It will be a job we have to takle in near future to get
all these people together.
I'm sure at the moment we don't even know for sure on which OSes/platforms
the code still builds.
However this is not my only concern: I'm also concerned about portability.
Portability to future OSes/platforms.
>
> After these lists are complete, the next step would be to evaluate what
> it takes to get stuff into the kernel on all these archs/platforms, how
> long release cycles usually take, what the respective kernel maintainers
> think about it (ie whether or not the would accept any of this) and so on.
>
> From my experience, getting gfx stuff into the linux kernel sometimes
> means smuggling it in behind Linus' back. An agony of its own kind if
> one knows Linus' attitude to fbdev drivers and graphics stuff in the
> kernel in general. No idea how other kernel maintainers like this idea,
> not at least when it comes to non-OSS, commercial kernels.
That's an even bigger problem: if commercial OSes don't provide a way
to build custom modules and demand loading them there is now way we
can go thru the kernel.
There are not that many commercial OSes around any more we support today
and most of them don't play a signifficant role any more.
Solaris/x86 may be the most importand one. There are not too many OS/2
users left, I haven't heared from LynxOS for quite a while and SCO has
a bad press anyway these days....
>
> My very humble $.02 as one who's been in X driver development and user
> support for a mere 4 years: Forcing people to change and reconfigure
> their kernel just to run the "current gui" is something I really can't
> imagine being a much appreciated idea. And the "gui" shouldn't really be
> able to take down the entire machine in case of a bug. Welcome to the
> world of Windows (and debugging hell, besides).
True!
>
> I can well agree on moving resource allocation stuff into the kernel if
> not there already; mode setup etc, however, I tend to think is userland
> stuff. Not even speaking of 2D, video, HW cursor, color management, etc
> (ie stuff that requires register access in the same way as mode setup).
>
Right. Also debugging a driver in user land is much simpler.
After you've gone thru hundreds of modify-build-test cycles to
get one combination of register settings right you know what
I mean :-/
> Hell, I guess I am one of the "10 to 15 percent".
>
Well, as a debian/i386 user you are very mainstream. Your opinion
may not be mainstream, however ;-)
Cheers,
Egbert.
From jdennis at redhat.com Tue Jul 6 07:38:19 2004
From: jdennis at redhat.com (John Dennis)
Date: Tue Jul 6 07:38:32 2004
<16618.37064.382589.401333@hermes.local>
Message-ID: <1089124699.26698.35.camel@finch.boston.redhat.com>
> We have already discussed a daemon solution. Which parts would have to
> live on the kernel level?
I have one suggestion, which is the current XFree86 derived
implementation over reaches its bounds and any rewrite should retain the
following as a goal:
You should assume the kernel in conjunction with other low level system
services such as ACPI have correctly enumerated and configured the PCI
bus topology and that VGA routing is correct. Unlike the current
implementation you should not write new values into PCI bridge registers
or in any way alter the hardware subsystem behind the kernel's back. You
should trust the kernel and cooperate with it. In the past the X server
has been a rude user mode guest who thought it knew more than the kernel
and as a consequence has machine checked (crashed) entire systems :-(
--
John Dennis <jdennis@redhat.com>
Date: Tue Jul 6 08:17:36 2004
<16618.37064.382589.401333@hermes.local>
On Tue, 2004-07-06 at 07:45, Egbert Eich wrote:
> When you are talking about kernel partition you tie yourself to a single
> OS - not necessarily a single architecture. This is what worries me a little
> bit.
What worries me and seems to be a design philosophy embedded in XFree86
is that in an attempt to be OS agnostic it implicitly declared itself
superior to the OS and attempted to supersede the OS. From my
perspective this is a fundamentally flawed model that ignores what we've
learned about the need to partition and layer responsibility in large
scale computer systems.
There are two areas in the current implementation that are prime
examples of this:
1) The XFree86 loader: One should assume the OS can dynamically load and
link modules and that the OS knows more about this than the X server. In
the past when very low level handling of object modules changed the X
Server blew up spectacularly and required surgery to very arcane pieces
of code none of which would have been necessary if the underlying system
services had been used. I might add being able run a debugger on a
running process would appear to be a novel concept ;-)
2) The PCI code: In the current implementation this code has direct
knowledge of PCI bridges and manipulates those bridges at the register
level. If a new bridge is introduced or any semantics change, or the
kernel's configuration of these bridges change things blow up really
really badly, i.e. your computer stops dead in it's tracks. Guess what?
PCI and system architecture is changing faster than the X server can
keep up with, nor should even attempt to.
I will grant you, most of these problems occurred on non-X86
architectures. As an individual who spent the better part of the last
two years trying to fix these problems so the X server didn't crash your
entire machine or roll over and die I was left scratching my head after
discovering the root cause many of these problems wondering why in heck
was the X server mucking in areas it had no business mucking with. Just
my 2 cents from someone in the trenches :-)
O.K., I feel better and I'll get off my soapbox now :-) :-)
But I really hope there are some lessons learned here as we march
forward.
--
Date: Tue Jul 6 08:22:16 2004
In-Reply-To: <1089127048.26698.115.camel@finch.boston.redhat.com>
<16618.37064.382589.401333@hermes.local>
<1089127048.26698.115.camel@finch.boston.redhat.com>
Message-ID: <20040706152214.GD32444@fooishbar.org>
On Tue, Jul 06, 2004 at 11:17:28AM -0400, John Dennis wrote:
> 1) The XFree86 loader: One should assume the OS can dynamically load and
> link modules and that the OS knows more about this than the X server. In
> the past when very low level handling of object modules changed the X
> Server blew up spectacularly and required surgery to very arcane pieces
> of code none of which would have been necessary if the underlying system
> services had been used. I might add being able run a debugger on a
> running process would appear to be a novel concept ;-)
What do you mean, 'in the past'? These problems have occurred very
recently, as new relocations have been introduced. It's far better to
leave module handling to the OS as much as possible.
In Debrix (the modular build of the X.Org server), dlloader is used
everywhere, and I feel tremendously good about it.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/f6f375f3/attach
ment.pgp
From keith at tungstengraphics.com Tue Jul 6 08:30:59 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Tue Jul 6 08:31:08 2004
In-Reply-To: <20040706152214.GD32444@fooishbar.org>
References: <16617.22371.859445.768739@hermes.local> <E1Bhdxj-0001vh-8X@evo.k
eithp.com> <16618.37064.382589.401333@hermes.local> <1089127048.2669
8.115.camel@finch.boston.redhat.com>
<20040706152214.GD32444@fooishbar.org>
Message-ID: <40EAC5B3.4050507@tungstengraphics.com>
Daniel Stone wrote:
> On Tue, Jul 06, 2004 at 11:17:28AM -0400, John Dennis wrote:
>
>>1) The XFree86 loader: One should assume the OS can dynamically load and
>>link modules and that the OS knows more about this than the X server. In
>>the past when very low level handling of object modules changed the X
>>Server blew up spectacularly and required surgery to very arcane pieces
>>of code none of which would have been necessary if the underlying system
>>services had been used. I might add being able run a debugger on a
>>running process would appear to be a novel concept ;-)
>
>
> What do you mean, 'in the past'? These problems have occurred very
> recently, as new relocations have been introduced. It's far better to
> leave module handling to the OS as much as possible.
>
> In Debrix (the modular build of the X.Org server), dlloader is used
> everywhere, and I feel tremendously good about it.
Hooray!
Keith
From matthieu.herrb at laas.fr Tue Jul 6 08:41:33 2004
From: matthieu.herrb at laas.fr (Matthieu Herrb)
Date: Tue Jul 6 08:41:38 2004
In-Reply-To: <40EAC5B3.4050507@tungstengraphics.com>
References: <16617.22371.859445.768739@hermes.local> <E1Bhdxj-0001vh-8X@evo.k
eithp.com> <16618.37064.382589.401333@hermes.local> <1089127048.2669
8.115.camel@finch.boston.redhat.com> <20040706152214.GD32444@fooishbar.org>
<40EAC5B3.4050507@tungstengraphics.com>
Message-ID: <40EAC82D.7070208@laas.fr>
Keith Whitwell wrote:
>> In Debrix (the modular build of the X.Org server), dlloader is used
>> everywhere, and I feel tremendously good about it.
>
>
> Hooray!
Is it possible to have OS independant binary modules with this loader?
--
Matthieu Herrb
-------------- next part --------------
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4071 bytes
Desc: S/MIME Cryptographic Signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/e88e9a49/smime.
bin
From ajax at nwnk.net Tue Jul 6 09:17:57 2004
From: ajax at nwnk.net (Adam Jackson)
Date: Tue Jul 6 08:48:35 2004
<16618.37064.382589.401333@hermes.local>
Message-ID: <200407061218.05041.ajax@nwnk.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 06 July 2004 11:17, John Dennis wrote:
> On Tue, 2004-07-06 at 07:45, Egbert Eich wrote:
> > When you are talking about kernel partition you tie yourself to a single
> > OS - not necessarily a single architecture. This is what worries me a
> > little bit.
I would disagree with this point. Think int10; some OSes need to do it with
an x86 emulator, but some can do it in vm86 mode directly. All that matters
with this API is that it exists and gets used. How that API is implemented
on various OSes will necessarily differ; but so what, we knew that, we
already have that with X. The kernel/user split is just a matter of whether
a particular piece of code lives in the library or in the kernel, and really
that's a compile-time flag; "Oh, WonderOS has an ioctl for passing video mode
registers for the MegaCo PrettyPixel 7000, so I'll use that instead of
mmap()ing the card and fiddling it myself". The internal design of the
library should be able to hide those sorts of details.
> <snip>
> 1) The XFree86 loader: One should assume the OS can dynamically load and
> link modules and that the OS knows more about this than the X server. In
> the past when very low level handling of object modules changed the X
> Server blew up spectacularly and required surgery to very arcane pieces
> of code none of which would have been necessary if the underlying system
> services had been used. I might add being able run a debugger on a
> running process would appear to be a novel concept ;-)
I have to agree. Right now we've got both a libc thunk layer and a
reimplementation of libdl in the server, all for a marginal (and I hear,
rarely realized) gain in module portability. I have trouble justifying that.
I'm currently working at fixing the drivers so the libdl loader is usable
again.
- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA6tC4W4otUKDs0NMRAiJVAJ4jX3NOIzKv8PEYPq2JIaKWhhvg2gCbB/aR
jRtV5geTmCbcz32W7pVbfT8=
=nIUj
-----END PGP SIGNATURE-----
Date: Tue Jul 6 09:05:54 2004
In-Reply-To: <40EAC82D.7070208@laas.fr>
<E1Bhdxj-0001vh-8X@evo.keithp.com> <16618.37064.382589.401333@herme
s.local>
<20040706152214.GD32444@fooishbar.org>
<40EAC5B3.4050507@tungstengraphics.com> <40EAC82D.7070208@laas.fr>
On Tue, 2004-07-06 at 11:41, Matthieu Herrb wrote:
> Is it possible to have OS independant binary modules with this loader?
Is it possible to have OS independent binary modules in the first place
when its the OS that is producing the binary module?
Sometimes, but its clearly not a reliable mechanism and I would argue of
dubious value as binaries are typically release engineered for specific
targets.
--
Date: Tue Jul 6 09:11:08 2004
Hash: SHA1
On Tuesday 06 July 2004 11:41, Matthieu Herrb wrote:
> Keith Whitwell wrote:
> > Daniel Stone wrote:
> >> In Debrix (the modular build of the X.Org server), dlloader is used
> >> everywhere, and I feel tremendously good about it.
> >
> > Hooray!
>
Short answer no, long answer yes. It's tricky but not impossible. To get a
portable ELF module, for example, you'd need to a) only use symbols defined
in the server (and the libraries it's linked against) or in other modules,
and b) not rely on any OS-specific features of the linker (versioned symbols
on Linux might be an instance of this, but are there any ELF platforms that
don't have this?). There might be one or two other caveats but that's all
that springs to mind ATM. That will get you portability among OSes with the
same ABI and a common subset of supported binary formats. I would expect,
for example, that Linux-x86-ELF modules would have little trouble on
FreeBSD-x86 (either directly or using their Linux emulation).
I would posit, however, that OS-independence in drivers is a false economy.
OSes are cheap, get a multi-boot rig and compile them all directly. Or use a
cross-compiler. From the perspective of the graphics card manufacturer,
you'd need to have the target platform around for testing anyway if you're
going to declare it a supported platform.
Finally, if all else fails, it may be possible to keep the old loader around
specifically for obstreperous vendors who don't feel like adding another
machine to the compile farm. This would need some hacking to make work - in
my tests the two module loaders are _not_ cross-callable - but it should be
doable.
- - ajax
iD8DBQFA6tYIW4otUKDs0NMRAiC7AJ9KhuR3DgMC0ExSB08vMkrZ9aPbqACePVRB
Oi/9/Fu07MowoL7h1jAX8sQ=
=GXSG
Date: Tue Jul 6 09:11:09 2004
Hash: SHA1
On Tuesday 06 July 2004 11:41, Matthieu Herrb wrote:
> > Daniel Stone wrote:
> >> In Debrix (the modular build of the X.Org server), dlloader is used
> >> everywhere, and I feel tremendously good about it.
> >
> > Hooray!
>
Short answer no, long answer yes. It's tricky but not impossible. To get a
portable ELF module, for example, you'd need to a) only use symbols defined
in the server (and the libraries it's linked against) or in other modules,
and b) not rely on any OS-specific features of the linker (versioned symbols
on Linux might be an instance of this, but are there any ELF platforms that
don't have this?). There might be one or two other caveats but that's all
that springs to mind ATM. That will get you portability among OSes with the
same ABI and a common subset of supported binary formats. I would expect,
for example, that Linux-x86-ELF modules would have little trouble on
FreeBSD-x86 (either directly or using their Linux emulation).
I would posit, however, that OS-independence in drivers is a false economy.
OSes are cheap, get a multi-boot rig and compile them all directly. Or use a
cross-compiler. From the perspective of the graphics card manufacturer,
you'd need to have the target platform around for testing anyway if you're
going to declare it a supported platform.
Finally, if all else fails, it may be possible to keep the old loader around
specifically for obstreperous vendors who don't feel like adding another
machine to the compile farm. This would need some hacking to make work - in
my tests the two module loaders are _not_ cross-callable - but it should be
doable.
- - ajax
iD8DBQFA6tYIW4otUKDs0NMRAiC7AJ9KhuR3DgMC0ExSB08vMkrZ9aPbqACePVRB
Oi/9/Fu07MowoL7h1jAX8sQ=
=GXSG
Date: Tue Jul 6 09:27:59 2004
<16618.37064.382589.401333@hermes.local>
<20040706152214.GD32444@fooishbar.org>
Message-ID: <20040706162757.GE32444@fooishbar.org>
On Tue, Jul 06, 2004 at 05:41:33PM +0200, Matthieu Herrb wrote:
> >Daniel Stone wrote:
> >>In Debrix (the modular build of the X.Org server), dlloader is used
> >>everywhere, and I feel tremendously good about it.
> >
> >Hooray!
>
OS-independent: quite possibly. Architecture-independent: no.
--
From krahn at niehs.nih.gov Tue Jul 6 09:27:29 2004
Date: Tue Jul 6 09:28:06 2004
<E1BdfYK-0000UK-Kd@evo.keithp.com> <16608.14200.939504.532986@herme
s.local> <40E13F9A.7030108@bitplanet.net> <16613.36429.355137.5415
0@xf11.fra.suse.de> <40E6D638.7060501@bitplanet.net>
<16617.36309.680473.400458@hermes.local>
Message-ID: <40EAD2F1.401@niehs.nih.gov>
Egbert Eich wrote:
> > ...
> >
> > > What I remember right now:
> > > 1.a. Clearify meaning of device type and device name in the XDeviceInfo
> > > struct. Type is an Atom form a fixed list.
> > > b. A device type touchpad is meaningless as it doesn't describe what
> > > device (stylus, eraser, mouse etc.) is attached.
I have always thought that the concept of a touchpad being multiple
devices is a problem. Really, it is a single device, with a single X,Y
valuator mechanism. The additional info is really an enum for which
stylus is in use. I would have designed the driver to have X,Y
valuators and one "stylus enum" valuator. But, I can see how this could
also create problems if you want the mouse stylus to emit pointer
events.
It does bring up the point that multi-device devices need to be
considered in updating the XINPUT design.
> >
> > Yeah, this bit from xf86Xinput.c:xf86ActivateDevice() doesn't help:
> >
> > local->atom = MakeAtom(local->name,
> > strlen(local->name),
> > TRUE);
> > AssignTypeAndName (dev, local->atom, local->name);
> >
> > i.e. it creates a atom for the device name and uses it as the type :-/.
>
> Yes, that is completely bogus.
>
> > Here's output from a modified xsetpointer -l:
> >
> > "Mouse0" XID=3, type=Mouse0 (115) [XPointer]
> > "keyboard" XID=4, type=NULL (0) [XKeyboard]
> > "stylus" XID=2, type=stylus (114) [XExtensionDevice]
> > "eraser" XID=1, type=eraser (113) [XExtensionDevice]
> > "cursor" XID=0, type=cursor (112) [XExtensionDevice]
> >
> > > 2. Make device controls more flexible. A device control currently
> > > is an XID. Make it an Atom.
> >
> > Can this be done in a backward compatible way or would we need a new
> > request? Btw, why is the device control both in the
> > XChangeDeviceControl() argument list and in the XDeviceControl struct?
> > That's redundant...
> >
>
> control is an XID in the XDeviceControl structure which is pretty much
> an unsigned long. This would match an Atom which is also an unsigned
> long. However in XGetDeviceControl() and XChangeDeviceControl() it is
> an int :-/ On the wire its a 32bit container. This would not create
> problems.
>
Changing the XDeviceControl id from XID to Atom should not be a problem,
although it is officially "Bad" to make an inconsistent change to an
established X function. However, backwards compatibility should be also
be easy since the only defined type, DEVICE_RESOLUTION, is essentially
guaranteed not to conflict with another device control atom.
The bigger problem with device controls is how to encapsulate the
device control data over the wire. If we don't use some standard data
packets, then new control types require server changes, which means it
is still not very extensible.
Given this, I think a better approach is to go ahead and keep the
compatible XID for control types, and define a set of well defined
private control types, which send an identifier (string?) along with
a fixed or variable length packet of char, short, or long data.
The event would be similar to XClientMessage, or XChangeProperty.
Variable length data is better, I think, unless variable length
data packets have more overhead. Maybe it is best to have both types.
Joe
From keith at tungstengraphics.com Tue Jul 6 09:27:55 2004
Date: Tue Jul 6 09:28:42 2004
In-Reply-To: <200407061240.41575.ajax@nwnk.net>
References: <16617.22371.859445.768739@hermes.local> <40EAC5B3.4050507@tungst
engraphics.com>
<40EAC82D.7070208@laas.fr> <200407061240.41575.ajax@nwnk.net>
Message-ID: <40EAD30B.3060000@tungstengraphics.com>
Adam Jackson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 06 July 2004 11:41, Matthieu Herrb wrote:
>
>>Keith Whitwell wrote:
>>
>>>Daniel Stone wrote:
>>>
>>>>In Debrix (the modular build of the X.Org server), dlloader is used
>>>>everywhere, and I feel tremendously good about it.
>>>
>>>Hooray!
>>
>>Is it possible to have OS independant binary modules with this loader?
>
>
> Short answer no, long answer yes. It's tricky but not impossible. To get a
> portable ELF module, for example, you'd need to a) only use symbols defined
> in the server (and the libraries it's linked against) or in other modules,
> and b) not rely on any OS-specific features of the linker (versioned symbols
> on Linux might be an instance of this, but are there any ELF platforms that
> don't have this?). There might be one or two other caveats but that's all
> that springs to mind ATM. That will get you portability among OSes with the
> same ABI and a common subset of supported binary formats. I would expect,
> for example, that Linux-x86-ELF modules would have little trouble on
> FreeBSD-x86 (either directly or using their Linux emulation).
>
> I would posit, however, that OS-independence in drivers is a false economy.
> OSes are cheap, get a multi-boot rig and compile them all directly. Or use a
> cross-compiler. From the perspective of the graphics card manufacturer,
> you'd need to have the target platform around for testing anyway if you're
> going to declare it a supported platform.
>
> Finally, if all else fails, it may be possible to keep the old loader around
> specifically for obstreperous vendors who don't feel like adding another
> machine to the compile farm. This would need some hacking to make work - in
> my tests the two module loaders are _not_ cross-callable - but it should be
> doable.
Ugh. That would be the ugliest. If it goes, it should go completely.
Note that most drivers nowadays include a kernel component, so OS-independent
modules in the userspace are pretty pointless.
Does anyone test that these modules actually can be run on another O/S? Does
anyone care if they can't? Does any vendor actually make use of this?
If someone really cares about cross-platform drivers, the module loader in
XFree86 isn't a great place to start. For starters, there's the kernel
problem I mentioned, but also I have to question how useful OS-independence is
if you don't also gain CPU-independence.
For my 2 cents, it's a feature that sounds useful but isn't, and just makes
life hard for people trying to do real work with the X server.
Keith
From jonsmirl at yahoo.com Tue Jul 6 09:36:04 2004
Date: Tue Jul 6 09:36:07 2004
--- John Dennis <jdennis@redhat.com> wrote:
> bus topology and that VGA routing is correct. Unlike the current
You can't make the assumptions about VGA routing. When secondary video
cards are reset by running their ROM, at the very least they enable
their VGA support. Sometimes they remap the bridges too.
We need kernel support for:
1) disabling all VGA devices
2) setting one VGA device active and get the bus routed to it
3) retrieving the board's VBIOS ROM.
This allow a user space reset program (they have to be user space since
they use VM86 mode) to disable all VGA devices, reset the card by
running the ROM, reenable the orginal VGA device.
#3 needs a special case. The kernel has to track which VGA device the
BIOS left active. When an app asks for the VBIOS ROM from this device,
you return the memory contents at C000:0. Some laptops compress the
VBIOS image of the primary adapter and this is where the uncompressed
version is stored. The kernel has to remember the boot device so that
if someone changes the active VGA device we will still know which
adapter the image at C000:0 belongs too.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
Date: Tue Jul 6 09:47:07 2004
In-Reply-To: <1089106507.6128.2.camel@bird>
--- Nicolas Boichat <nicolas@boichat.ch> wrote:
> Thanks for the idea, you're probably right.
>
> I have a nVidia card so I'll work on a kernel driver.
>
> Best regards,
>
> Nicolas
I just checked in current 2.6.7 and the Nvidia framebuffer driver
already has an I2C driver. So you would just need to load the
framebuffer driver and i2c-dev. Then you can write a user space app,
it's pretty easy.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
From keithp at keithp.com Tue Jul 6 09:48:01 2004
Date: Tue Jul 6 09:48:12 2004
<16618.37064.382589.401333@hermes.local>
Message-ID: <E1Bht6w-0001M9-Bb@evo.keithp.com>
> When you are talking about kernel partition you tie yourself to a single
> OS - not necessarily a single architecture. This is what worries me a little
> bit.
Which is why I'd like to see some experimentation in this area. We've
discovered several places where the current 'everything in user mode' just
can't work (interrupt routing, PCI reconfiguration among others). The
question is precisely where the boundary should be drawn and how the
kernel interfaces should be designed.
I'm not sure we know the right answer yet, so providing a mechanism for
experimentation from which the X server remains aloof will allow various
techniques to be explored without affecting the overall system
architecture.
We can also design the kernel interfaces in such a way as to improve
portability across operating systems; the DRI system requires kernel
support and yet runs on BSD and Linux (at least).
Let's keep our options open, let developers experiment and see what
happens.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/b142bdf0/attach
ment.pgp
Date: Tue Jul 6 09:53:58 2004
<16618.35543.177687.150551@hermes.local>
Message-ID: <E1BhtCX-0001MT-Oe@evo.keithp.com>
> If you consider fbdev as something that lives solely in the kernel
> the only solution would be to place most - if not all - of the
> functionality mentioned above into the kernel.
I don't think this is a requirement. The kernel now provides mechanisms to
push functionality required by the kernel up to user mode. For the
graphics device, we can pend initialization until user mode is accessible
and initialize the graphics device at that point.
> VRAM coordination for printk's is also tricky: on some chipsets you
> need to know if the chipset is idle. If the kernel can still communicate
> with the daemon process it can let this handle the output.
That's actually very difficult -- printk can occur at interrupt time at
which point no communication with user mode is possible. For cards with
this limitation (which seems to be fewer these days than a few years ago),
it may well be necessary to pend some printk output to synchronize with
user mode device access. Alternatively, you could push even more code
down into the kernel and build a full kernel-based graphics driver (like
DRI). For some systems, this may well be the right trade off.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/e7583410/attach
ment-0001.pgp
From nicolas at boichat.ch Tue Jul 6 10:16:02 2004
Date: Tue Jul 6 10:03:34 2004
Yes I saw this new driver.
Thanks for the tip concerning the i2c-dev module.
Regards,
Nicolas Boichat
Le mar 06/07/2004 ? 18:47, Jon Smirl a ?crit :
> --- Nicolas Boichat <nicolas@boichat.ch> wrote:
> > Thanks for the idea, you're probably right.
> >
> > I have a nVidia card so I'll work on a kernel driver.
> >
> > Best regards,
> >
> > Nicolas
>
> I just checked in current 2.6.7 and the Nvidia framebuffer driver
> already has an I2C driver. So you would just need to load the
> framebuffer driver and i2c-dev. Then you can write a user space app,
> it's pretty easy.
>
> =====
> Jon Smirl
>
>
>
> __________________________________
> Do you Yahoo!?
> Take Yahoo! Mail with you! Get it on your mobile phone.
> http://mobile.yahoo.com/maildemo
>
Date: Tue Jul 6 10:07:14 2004
> You can't make the assumptions about VGA routing. When secondary video
> cards are reset by running their ROM, at the very least they enable
> their VGA support. Sometimes they remap the bridges too.
The first part I'll buy, the second part about VBIOS remapping
(upstream) bridges feels wrong, but nothing would surprise me.
> We need kernel support for:
Precisely, its the kernel that should be managing all this.
> #3 needs a special case. The kernel has to track which VGA device the
> BIOS left active. When an app asks for the VBIOS ROM from this device,
> you return the memory contents at C000:0. Some laptops compress the
> VBIOS image of the primary adapter and this is where the uncompressed
> version is stored. The kernel has to remember the boot device so that
> if someone changes the active VGA device we will still know which
> adapter the image at C000:0 belongs too.
Yes, and this is compounded by the fact that the PCI spec demands that
BIOS images be executed from host memory, not card memory. CPU
architecture and OS designs impose restrictions on executable memory
requirements that the kernel is aware but generic user level code may be
ignorant of, not to mention the low level firmware the OS cooperates
with, best to let the kernel/firmware do its job.
--
Date: Tue Jul 6 11:17:12 2004
In-Reply-To: <E1Bht6w-0001M9-Bb@evo.keithp.com>
> Which is why I'd like to see some experimentation in this area. We've
> discovered several places where the current 'everything in user mode'
Other areas to consider:
1) If we stop doing things in user mode, X doesn't have to run as root
any more.
2) Don't for get about OpenGL. In the model where X runs on top of
OpenGL, the OpenGL system has already taken care of all of the video
hardware before X even loads.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From torriem at chem.byu.edu Tue Jul 6 11:22:01 2004
From: torriem at chem.byu.edu (Michael L Torrie)
Date: Tue Jul 6 11:22:26 2004
Message-ID: <1089138120.4257.15.camel@isengard>
On Tue, 2004-07-06 at 12:17, Jon Smirl wrote:
> > Which is why I'd like to see some experimentation in this area. We've
> > discovered several places where the current 'everything in user mode'
>
> Other areas to consider:
>
> 1) If we stop doing things in user mode, X doesn't have to run as root
> any more.
Would you expect all other OSs out there (windows, freebsd, etc) to also
provide this kernel-level support? Or will X become linux-only?
>
> 2) Don't for get about OpenGL. In the model where X runs on top of
> OpenGL, the OpenGL system has already taken care of all of the video
> hardware before X even loads.
>
> =====
> Jon Smirl
>
>
>
> __________________________________
> Do you Yahoo!?
>
> _______________________________________________
> xorg mailing list
--
Michael L Torrie <torriem@chem.byu.edu>
From p.postmus at st.hanze.nl Tue Jul 6 12:13:26 2004
From: p.postmus at st.hanze.nl (Peter Postmus)
Date: Tue Jul 6 12:14:00 2004
Subject: [Xorg] Can I use the X logo?
References: <40D9BFAE.8060801@bitplanet.net> <40E6D638.7060501@bitplanet.net>
<16617.36309.680473.400458@hermes.local>
Message-ID: <200407062113.26227.p.postmus@st.hanze.nl>
Hi,
A number of students - myself included - are planning to create a Linux
distro, Primarily because we want to learn about the internals of a Linux
Operating System (non-profit). We will start with Linux From Scratch. I've
created a logo for the project, which includes the X logo. It can be found on
http://starbase218.ath.cx/deux-linux.png. Can you tell me if I can use this
logo freely?
--
Met vriendelijke groeten,
With kind regards,
Peter Postmus
WWW: http://starbase218.ath.cx
Date: Tue Jul 6 13:48:47 2004
In-Reply-To: <1089138120.4257.15.camel@isengard>
--- Michael L Torrie <torriem@chem.byu.edu> wrote:
> On Tue, 2004-07-06 at 12:17, Jon Smirl wrote:
> > --- Keith Packard <keithp@keithp.com> wrote:
> > > Which is why I'd like to see some experimentation in this area.
> We've
> > > discovered several places where the current 'everything in user
> mode'
> >
> > Other areas to consider:
> >
> > 1) If we stop doing things in user mode, X doesn't have to run as
> root
> > any more.
>
> Would you expect all other OSs out there (windows, freebsd, etc) to
> also
> provide this kernel-level support? Or will X become linux-only?
X just needs to be changed to call a separate library for this stuff.
On Linux this library would be small and use a lot of kernel functions.
On other OS's this library would be much larger.
A good way to start is to split off the current X code into a
standalone library. For OS's without the kernel support they would
continue to use this existing code that has been moved to the library.
Once the library interface is determined, we can build a Linux version
that relies on the kernel for most things.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From ufz6 at rz.uni-karlsruhe.de Tue Jul 6 14:10:38 2004
Date: Tue Jul 6 14:07:58 2004
Subject: [Xorg] X Application does not receive Events
Message-ID: <E1BhxAR-0000Ad-00@mailgate.rz.uni-karlsruhe.de>
I use the a X Server which based on your project to run Java 3D Window
Manager, but X11 based Application does not work fine specially on
Gnome. My Work is to run also X11 Application under the modified Version,
therefore I study the X Server Code, but AS you know it is a big project.
My Situation here that KDE Window Manager draw a frame (with minimize,
maximize. bottom) around all popup windows including menus, list box etc. in
Gnome Window Manager it does not draw such a frame but menus, etc does not
displayed.
It seems to me that window manager on KDE receive also MapRequest Event,
when client try to map a popup menu. Normal those clients set the
override-redirect
<http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html>
attribute to TRUE, so that a Window Manager does not receive MapRequest
Events. Therefore KDE draw always a frame around popup window, because it
may be does not check whether this requested Window is a Sub window of the
main Client Window. In Gnome Window Manager I suppose that they check if
this window is a parent of the Root window or not, if not they drop this
event and therefore Xserver does not map those Window and therefore they
will not displayed.

It could be that the XServer (our modified Server) does not check this
override-redirect
<http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html>
attribute, so it redirects this Request to Window Manager.
That all an Idea about the problem, I can not say if it correct. (Correct me
if I am wrong)

You have more Experience with X Server Code, could tell me where I can find
(code I main) where X Server redirect the MapRequest Event (for time saving
and to check my suppose of the problem).

Amir

-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040706/ea97f3eb/attachm
ent.html
From p.postmus at st.hanze.nl Tue Jul 6 15:15:15 2004
From: p.postmus at st.hanze.nl (Peter Postmus)
Date: Tue Jul 6 15:15:48 2004
Subject: [Xorg] Can I use the X logo?
In-Reply-To: <200407062112.i66LCM418359@magic.shiman.com>
References: <200407062112.i66LCM418359@magic.shiman.com>
Message-ID: <200407070015.16075.p.postmus@st.hanze.nl>
On Tuesday 06 July 2004 23:12, Leon Shiman wrote:
> Hi Peter!
>
> The X Logo is used to identify the X Window System and X Window System
> components. X.Org and the X.Org Foundation have both previously expressed a
> strong interest in protecting its use.
>
> My personal opinion is that this is NOT an appropriate use of the X logo,
> and see no reason why you cannot use another large X in your design. I
> cannot understand why you would want to use it this way. X is a critical
> technology for desktop Linux, but does not uniquely label your release.
>
> I have been responsible for development and reproduction by X.Org of the
> logo for some time, and would be happy to work with you on your design.
>
> Leon
>
> (member, X.Org Foundation BOD)
>
Well, that's why I asked. I thought it might be protected. I think the X logo
looks very good, and because - as you already mentioned - X is an important
technology for desktop Linux, I wanted to use it. OTOH, you are right in that
it doesn't uniquely label our release.
Anyway, thanks for offering your help. I want to explore the possibilities of
the GIMP myself first, but I'll let you know if I mess up ;).
--
Met vriendelijke groeten,
With kind regards,
Peter Postmus
WWW: http://starbase218.ath.cx
From carl at personnelware.com Tue Jul 6 16:13:26 2004
From: carl at personnelware.com (Carl Karsten)
Date: Tue Jul 6 16:08:26 2004
Subject: [Xorg] XIO: fatal IO error 104
Message-ID: <124001c463ae$d805bad0$1e01a8c0@cnt496>
2 weeks ago, CVS build worked. Now startx drops me back to the console with the
following (the rest is in the log):
Fatal server error:
Caught signal 11. Server aborting
Please consult the The X.Org Foundation support
at http://wiki.X.Org
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional
information.
XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining
Below is all the info about my box.
Carl K
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Celeron (Coppermine)
stepping : 3
cpu MHz : 601.498
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
mmx fxsr sse
bogomips : 1191.93
Gentoo Base System version 1.4.10
Linux LinuxBook1 2.6.7-bk18 #1 Tue Jul 6 14:17:14 GMT 2004 i686 Celeron
(Coppermine) GenuineIntel GNU/Linux
-rwxr-xr-x 1 root root 1302844 Feb 19 12:06 /lib/libc-2.3.2.so
lrwxrwxrwx 1 root root 13 May 10 19:01 /lib/libc.so.6 ->
libc-2.3.2.so
GNU ld version 2.14.90.0.7 20031029
GNU assembler 2.14.90.0.7 20031029
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of ì686-pc-linux-gnu'.
Linux version 2.6.7-bk18 (carl@LinuxBook1) (gcc version 3.3.2 20031218 (Gentoo
Linux 3.3.2-r5, propolice-3.3-7)) #1 Tue Jul 6 14:17:14 GMT 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fef0000 (usable)
BIOS-e820: 000000000fef0000 - 000000000fef3000 (ACPI NVS)
BIOS-e820: 000000000fef3000 - 000000000ff00000 (ACPI data)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
254MB LOWMEM available.
On node 0 totalpages: 65264
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61168 pages, LIFO batch:14
HighMem zone: 0 pages, LIFO batch:1
DMI not present.
ACPI: RSDP (v000 IntelR ) @ 0x000f6f70
ACPI: RSDT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0fef3000
ACPI: FADT (v001 IntelR AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0fef3040
ACPI: DSDT (v001 INTELR AWRDACPI 0x00001000 MSFT 0x0100000b) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
Built 1 zonelists
Kernel command line: root=/dev/hda3 vga=6
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 601.498 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x60
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 254888k/261056k available (1939k kernel code, 5460k reserved, 659k data,
364k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1191.93 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000
CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Celeron (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 601.0280 MHz.
..... host bus clock speed is 66.0808 MHz.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb130, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20040326
tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired
Parsing all Control
Methods:........................................................................
Table [DSDT](id F004) - 310 Objects with 28 Devices 72 Methods 30 Regions
ACPI Namespace successfully loaded at root c040757c
ACPI: IRQ9 SCI: Edge set to Level Trigger.
evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful
evgpeblk-0867 [06] ev_create_gpe_block : GPE 00 to 15 [_GPE] 2 regs at
000000000000402C on int 9
evgpeblk-0925 [06] ev_create_gpe_block : Found 0 Wake, Enabled 0 Runtime GPEs
in this block
evgpeblk-0867 [06] ev_create_gpe_block : GPE 16 to 31 [_GPE] 2 regs at
0000000000004028 on int 9
evgpeblk-0925 [06] ev_create_gpe_block : Found 0 Wake, Enabled 0 Runtime GPEs
in this block
Completing Region/Field/Buffer/Package
initialization:.................................................................
.....
Initialized 30/30 Regions 16/16 Fields 18/18 Buffers 6/6 Packages (319 nodes)
Executing all Device _STA and_INI methods:..............................
30 Devices found containing: 30 _STA, 0 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 *4 5 6 7 9 10 11 12 14 15)
PCI: Using ACPI for IRQ routing
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:01.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 4
ACPI: PCI interrupt 0000:00:1f.2[D] -> GSI 4 (level, low) -> IRQ 4
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 3
ACPI: PCI interrupt 0000:01:05.1[B] -> GSI 3 (level, low) -> IRQ 3
Machine check exception polling timer started.
devfs: 2004-01-31 Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
udf: registering filesystem
Initializing Cryptographic API
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Processor [CPU0] (supports C1 C2, 2 throttling states)
Non-volatile memory driver v1.2
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected an Intel i810 Chipset.
agpgart: Maximum main memory to use for agp memory: 202M
agpgart: AGP aperture is 64M @ 0xd0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH0: IDE controller at PCI slot 0000:00:1f.1
ICH0: chipset revision 1
ICH0: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
hda: WDC WD307AA-00BAA0, ATA DISK drive
hdb: TOSHIBA DVD-ROM SD-M1502, ATAPI CD/DVD-ROM drive
Using anticipatory io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=59598/16/63, UDMA(33)
/dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4
hdb: ATAPI 48X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard on isa0060/serio0
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S3 S4 S4bios S5)
ReiserFS: hda3: found reiserfs format "3.6" with standard journal
ReiserFS: hda3: using ordered data mode
ReiserFS: hda3: journal params: device hda3, size 8192, journal first block 18,
max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda3: checking transaction log (hda3)
ReiserFS: hda3: Using r5 hash to sort names
VFS: Mounted root (reiserfs filesystem) readonly.
Freeing unused kernel memory: 364k freed
Adding 506036k swap on /dev/hda2. Priority:-1 extents:1
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
eth0: Davicom DM9102 at pci0000:01:04.0, 00:d0:09:1d:51:13, irq 11.
I810FB: fb0 : Intel(R) 810 Framebuffer Device v0.9.0
I810FB: Video RAM : 16384K
I810FB: Monitor : H: 29-30 KHz V: 60-60 Hz
I810FB: Mode : 640x480-8bpp@60Hz
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hda4, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Real Time Clock Driver v1.12
nfs warning: mount version older than kernel
i2c_adapter i2c-0: registered as adapter #0
i2c-core: driver it87 registered.
i2c_adapter i2c-0: found normal isa entry for adapter 9191, addr 0290
i2c_adapter i2c-0: client [it87] registered to adapter
registering 0-0290
[drm] Initialized i810 1.4.0 20030605 on minor 0: Intel Corp. 82810 CGC [Chipset
Graphics Controller]
mtrr: base(0xd0000000) is not aligned on a size(0x12c000) boundary
Console: switching to colour frame buffer device 80x30
Identifier "XFree86 Configured"
EndSection
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
ModulePath "/usr/X11R6/lib/modules"
FontPath "/usr/X11R6/lib/X11/fonts/misc/"
# FontPath "/usr/X11R6/lib/X11/fonts/Speedo/"
# FontPath "/usr/X11R6/lib/X11/fonts/Type1/"
# FontPath "/usr/X11R6/lib/X11/fonts/CID/"
FontPath "/usr/X11R6/lib/X11/fonts/75dpi/"
FontPath "/usr/X11R6/lib/X11/fonts/100dpi/"
EndSection
Section "Module"
Load "record"
SubSection "extmod"
Option "omit xfree86-dga"
EndSubSection
Load "dbe"
Load "dri"
Load "glx"
# Load "xtt"
Load "xtrap"
Load "type1"
Load "speedo"
EndSection
Driver "keyboard"
EndSection
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/psaux"
EndSection
Section "Monitor"
VendorName "Vendor"
ModelName "Model"
# VertRefresh 43-65
VertRefresh 60
HorizSync 30-50
EndSection
Section "Device"
Option "NoAccel" "0" # [<bool>]
#Option "ColorKey" # 
#Option "CacheLines" # 
#Option "Dac6Bit" # [<bool>]
#Option "NoDDC" # [<bool>]
#Option "ShowCache" # [<bool>]
Option "DRI"
Option "XvMCSurfaces" "6"
Identifier "Card0"
Driver "i810"
VendorName "Intel Corp."
BoardName "82810 CGC [Chipset Graphics Controller]"
BusID "PCI:0:1:0"
EndSection
Section "Screen"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 16
Depth 1
EndSubSection
Depth 4
EndSubSection
Depth 8
EndSubSection
Depth 15
EndSubSection
Depth 16
Modes "800x600"
EndSubSection
Depth 24
# Modes "800x600" "640x480"
Modes "800x600"
EndSubSection
EndSection
Section "DRI"
Mode 0666
EndSection
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.7
Build Operating System: Linux 2.6.7-bk18 i686 [ELF]
Current Operating System: Linux LinuxBook1 2.6.7-bk18 #1 Tue Jul 6 14:17:14 GMT
2004 i686
Build Date: 06 July 2004
Before reporting problems, check http://wiki.X.Org
to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul 6 17:26:33 2004
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "XFree86 Configured"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "Monitor0"
(**) | |-->Device "Card0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Keyboard: CustomKeycode disabled
(**) FontPath set to
"/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X
11/fonts/100dpi/"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R6/lib/modules"
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.2
X.Org Video Driver: 0.7
X.Org XInput driver : 0.4
X.Org Server Extension : 0.2
X.Org Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="X.Org Foundation"
ABI class: X.Org Video Driver, version 0.7
(--) using VT number 7
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,7120 card 8086,7120 rev 02 class 06,00,00 hdr 00
(II) PCI: 00:1e:0: chip 8086,2428 card 0000,0000 rev 01 class 06,04,00 hdr 01
(II) PCI: 00:1f:0: chip 8086,2420 card 0000,0000 rev 01 class 06,01,00 hdr 80
(II) PCI: 00:1f:2: chip 8086,2422 card 0000,0000 rev 01 class 0c,03,00 hdr 00
(II) PCI: 01:05:0: chip 13f6,0111 card 13f6,0111 rev 10 class 04,01,00 hdr 80
(II) PCI: 01:05:1: chip 13f6,0211 card 13f6,0211 rev 10 class 07,80,00 hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:30:0), (0,1,1), BCTRL: 0x0006 (VGA_EN is cleared)
[0] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[1] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[2] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B]
[3] -1 0 0x0000cc00 - 0x0000ccff (0x100) IX[B]
[0] -1 0 0xd4000000 - 0xd5ffffff (0x2000000) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(--) PCI:*(0:1:0) Intel Corp. 82810 CGC [Chipset Graphics Controller] rev 2, Mem
@ 0xd0000000/26, 0xd6000000/19
(II) Addressable bus resource ranges are
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) OS-reported resource ranges:
[0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B)
[1] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B)
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) Active PCI resource ranges:
[0] -1 0 0xd5000000 - 0xd500007f (0x80) MX[B]
[1] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[2] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) MX[B](B)
[3] -1 0 0x0000c800 - 0x0000c83f (0x40) IX[B]
[4] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[5] -1 0 0x0000c000 - 0x0000c07f (0x80) IX[B]
[6] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[7] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
(II) Active PCI resource ranges after removing overlaps:
[0] -1 0 0xd5000000 - 0xd500007f (0x80) MX[B]
[1] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[3] -1 0 0x0000c800 - 0x0000c83f (0x40) IX[B]
[4] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[5] -1 0 0x0000c000 - 0x0000c07f (0x80) IX[B]
[6] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[7] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
(II) OS-reported resource ranges after removing overlaps with PCI:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) All system resource ranges:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xd5000000 - 0xd500007f (0x80) MX[B]
[6] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[10] -1 0 0x0000c800 - 0x0000c83f (0x40) IX[B]
[11] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[12] -1 0 0x0000c000 - 0x0000c07f (0x80) IX[B]
[13] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[14] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
(II) LoadModule: "record"
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="X.Org Foundation"
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension RECORD
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="X.Org Foundation"
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="X.Org Foundation"
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="X.Org Foundation"
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
(II) Loading extension XFree86-DRI
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="X.Org Foundation"
(II) Loading extension GLX
(II) LoadModule: "xtrap"
(II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a
(II) Module xtrap: vendor="X.Org Foundation"
(II) Loading extension DEC-XTRAP
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="X.Org Foundation"
(II) Loading font Type1
(II) Loading font CID
(II) LoadModule: "speedo"
(II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a
(II) Module speedo: vendor="X.Org Foundation"
(II) Loading font Speedo
(II) LoadModule: "i810"
(II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o
(II) Module i810: vendor="X.Org Foundation"
Module class: X.Org Video Driver
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="X.Org Foundation"
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.4
(II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100,
i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G
(II) Primary Device is: PCI 00:01:0
(--) Chipset i810 found
(II) resource ranges after xf86ClaimFixedResources() call:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xd5000000 - 0xd500007f (0x80) MX[B]
[6] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[8] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[9] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[10] -1 0 0x0000c800 - 0x0000c83f (0x40) IX[B]
[11] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[12] -1 0 0x0000c000 - 0x0000c07f (0x80) IX[B]
[13] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[14] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
(II) resource ranges after probing:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xd5000000 - 0xd500007f (0x80) MX[B]
[6] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[8] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
[9] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
[10] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
[11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[13] -1 0 0x0000c800 - 0x0000c83f (0x40) IX[B]
[14] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[15] -1 0 0x0000c000 - 0x0000c07f (0x80) IX[B]
[16] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[17] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
[18] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[19] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="X.Org Foundation"
(**) I810(0): Depth 16, (--) framebuffer bpp 16
(==) I810(0): RGB weight 565
(==) I810(0): Default visual is TrueColor
(**) I810(0): Option "NoAccel" "0"
(**) I810(0): Option "DRI"
(**) I810(0): Option "XvMCSurfaces" "6"
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Loading /usr/X11R6/lib/modules/libvbe.a
(II) Module vbe: vendor="X.Org Foundation"
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/X11R6/lib/modules/linux/libint10.a
(II) Module int10: vendor="X.Org Foundation"
(II) I810(0): initializing int10
(II) I810(0): Primary V_BIOS segment is: 0xc000
(II) I810(0): VESA BIOS detected
(II) I810(0): VESA VBE Version 3.0
(II) I810(0): VESA VBE Total Mem: 1024 kB
(II) I810(0): VESA VBE OEM: Intel810(TM) Graphics Chip Accelerated VGA BIOS
(II) I810(0): VESA VBE OEM Software Rev: 3.0
(II) I810(0): VESA VBE OEM Vendor: Intel Corporation
(II) I810(0): VESA VBE OEM Product: i810 Graphics Controller
(II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="X.Org Foundation"
(II) I810(0): VESA VBE DDC supported
(II) I810(0): VESA VBE DDC Level none
(II) I810(0): VESA VBE DDC transfer in appr. 0 sec.
(II) I810(0): VESA VBE DDC read failed
(--) I810(0): Chipset: "i810"
(--) I810(0): Linear framebuffer at 0xD0000000
(--) I810(0): IO registers at addr 0xD6000000
(II) I810(0): I810CheckAvailableMemory: 190392k available
(==) I810(0): Will alloc AGP framebuffer: 8192 kByte
(==) I810(0): Using gamma correction (1.0, 1.0, 1.0)
(II) I810(0): Monitor0: Using hsync range of 30.00-50.00 kHz
(II) I810(0): Monitor0: Using vrefresh value of 60.00 Hz
(II) I810(0): Clock range: 9.50 to 163.00 MHz
(II) I810(0): Not using default mode "640x350" (vrefresh out of range)
(II) I810(0): Not using default mode "320x175" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (hsync out of range)
(II) I810(0): Not using default mode "1024x768" (unknown reason)
(II) I810(0): Not using default mode "1024x768" (width too large for virtual
size)
(--) I810(0): Virtual size is 800x600 (pitch 1024)
(**) I810(0): *Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz
(II) I810(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628
+hsync +vsync
(**) I810(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 60.0 Hz
(II) I810(0): Modeline "640x480" 25.20 640 656 752 800 480 490 492
525 -hsync -vsync
(==) I810(0): DPI set to (75, 75)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/X11R6/lib/modules/libfb.a
(II) Module fb: vendor="X.Org Foundation"
ABI class: X.Org ANSI C Emulation, version 0.2
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="X.Org Foundation"
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Loading /usr/X11R6/lib/modules/libramdac.a
(II) Module ramdac: vendor="X.Org Foundation"
(II) Loading sub module "shadowfb"
(II) LoadModule: "shadowfb"
(II) Loading /usr/X11R6/lib/modules/libshadowfb.a
(II) Module shadowfb: vendor="X.Org Foundation"
(**) I810(0): page flipping disabled
(**) I810(0): 6 XvMC Surfaces Requested.
(II) Loading sub module "dri"
(II) Reloading /usr/X11R6/lib/modules/extensions/libdri.a
(II) UnloadModule: "dri"
(EE) I810: Failed to load module "dri" (once-only module, 0)
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
[0] 0 0 0xd6000000 - 0xd607ffff (0x80000) MS[B]
[1] 0 0 0xd0000000 - 0xd3ffffff (0x4000000) MS[B]
[4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[7] -1 0 0xd5000000 - 0xd500007f (0x80) MX[B]
[8] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
[11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
[12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
[13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[15] -1 0 0x0000c800 - 0x0000c83f (0x40) IX[B]
[16] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[17] -1 0 0x0000c000 - 0x0000c07f (0x80) IX[B]
[18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[19] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
[20] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
[21] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:01.0
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci:0000:00:01.0
(II) I810(0): [drm] DRM interface version 1.2
(II) I810(0): [drm] created "i810" driver at busid "pci:0000:00:01.0"
(II) I810(0): [drm] added 8192 byte SAREA at 0xd4a90000
(II) I810(0): [drm] mapped SAREA 0xd4a90000 to 0x401d6000
(II) I810(0): [drm] framebuffer handle = 0xd0000000
(II) I810(0): [drm] added 1 reserved context for kernel
(II) I810(0): [drm] Registers = 0xd6000000
(II) I810(0): [agp] dcacheHandle : 0x0
(II) I810(0): [agp] GART: no dcache memory found
(II) I810(0): [agp] Bound backbuffer memory
(II) I810(0): [agp] Bound depthbuffer memory
(II) I810(0): [agp] Bound System Texture Memory
(II) I810(0): GART: Allocated 7MB for HWMC
(II) I810(0): [agp] GART: Allocated 4K for mouse cursor image
(II) I810(0): [agp] GART: ARGB cursor alloc failed
(II) I810(0): Adding 768 scanlines for pixmap caching
*** If unresolved symbols were reported above, they might not
*** be the reason for the server aborting.
Fatal server error:
for help.
information.
From michel at daenzer.net Tue Jul 6 16:48:47 2004
From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=)
Date: Tue Jul 6 16:49:02 2004
<16618.29108.552996.705856@hermes.local>
<16618.46402.119628.614393@hermes.local>
On Tue, 2004-07-06 at 16:20 +0200, Egbert Eich wrote:
>
> Thomas Winischhofer writes:
> >
> > Well, in reality they don't have to. Looking at each others code has
> > been done, is being done and will be done anyway. A bit more of
> > cooperation between fbdev and X driver developers (if not identical)
> > would minimize this "agony" (if any). And finally: fbdev drivers are
>
> There still is a little obstacle that is tied to the license of the
> drivers. Kernel drivers are GPL.
The DRM drivers aren't, at least not exclusively.
> To use them as a sample to derive code for an MIT Licensed driver one
> would have to go thru a 'clean room' step.
The author can always dual license his code.
Of course, this isn't to say I wouldn't welcome one driver to rule them
all. :)
--
Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
Date: Tue Jul 6 16:49:49 2004
In-Reply-To: <40EA7D52.1030903@winischhofer.net>
<16618.29108.552996.705856@hermes.local>
On Tue, 2004-07-06 at 12:22 +0200, Thomas Winischhofer wrote:
>
> From my experience, getting gfx stuff into the linux kernel sometimes
> means smuggling it in behind Linus' back. An agony of its own kind if
> one knows Linus' attitude to fbdev drivers and graphics stuff in the
> kernel in general.
Actually, my impression has been that his opinion on this has been
changing; for one, he must be using fbcon on his G5. :) He was also
fairly active on the dri-devel list for a while.
> My very humble $.02 as one who's been in X driver development and user
> support for a mere 4 years: Forcing people to change and reconfigure
> their kernel just to run the "current gui" is something I really can't
> imagine being a much appreciated idea. And the "gui" shouldn't really be
> able to take down the entire machine in case of a bug. Welcome to the
> world of Windows (and debugging hell, besides).
I basically agree, let's not pretend a root daemon is all that much
better though. Either will probably be better in some aspects, worse in
others.
--
Date: Tue Jul 6 17:36:53 2004
In-Reply-To: Your message of "Wed, 07 Jul 2004 01:49:39 +0200."
<1089157779.17840.54.camel@localhost>
Message-ID: <E1Bi0QI-0001Z5-WE@evo.keithp.com>
Around 1 o'clock on Jul 7, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote:
> I basically agree, let's not pretend a root daemon is all that much
> better though. Either will probably be better in some aspects, worse in
> others.
I concur with this sentiment -- any code directly manipulating the device
registers runs a reasonable risk of corrupting the machine state. This
makes the X server or this proposed daemon equal in many ways to the
kernel.
One thing I'd like to see is a general reduction of code that runs in the
same address space as the 'scary' bits. Starting with the device
initialization and mode selection logic makes good sense as none of that is
particularily performance sensitive. This should give us significant
freedom of choice in implementation.
The remaining 'scary' code is largely the accelerated rendering bits; DRI
shows one solution to that problem, albiet with a significant kernel
component.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/248106bb/attach
ment.pgp
From afonsofc at hotmail.com Tue Jul 6 19:37:27 2004
From: afonsofc at hotmail.com (Francisco Afonso)
Date: Tue Jul 6 19:43:05 2004
Subject: [Xorg] XDrawArc
Message-ID: <BAY1-F33ZhNfv57kVwy00003329@hotmail.com>
I have some questions about XDrawArc:
a) What maximum values are accepted for origin coordinates and diameter?
b) Is it possible to crash the client/server for large values (e.g. stack
overflow)?
c) Does it use recursion?
Francisco Afonso
_________________________________________________________________
MSN Messenger: instale grtis e converse com seus amigos.
http://messenger.msn.com.br
From roland.mainz at nrubsig.org Tue Jul 6 20:03:07 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Tue Jul 6 20:03:39 2004
Subject: [Xorg] Resync branches...
Message-ID: <40EB67EB.DA2674B2@nrubsig.org>
Hi!
----
Does anyone here have a _simple_ script which can sync two CVS branches
? I'd like to breath live into an old branch and update it to "trunk",
including the special attributes of files in the CVS (execute flag,
binary flag etc.) ...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Tue Jul 6 20:29:00 2004
In-Reply-To: <E1Bi0QI-0001Z5-WE@evo.keithp.com>
> One thing I'd like to see is a general reduction of code that runs in
> the same address space as the 'scary' bits. Starting with the device
> initialization and mode selection logic makes good sense as none of
> that is particularily performance sensitive. This should give us
> significant freedom of choice in implementation.
Mode setting code is large. If you add up everything for the radeon it
is about 100K. Parts of this need to be in the kernel. For example the
Linux kernel has a well defined framework for I2C (used to retrieve
DDC). The IOCTL that actually sets the mode bits into the registers
should be in the kernel to remove the need for X to be root. But those
two things add up to about 5K of code. The rest of this code is open to
debate where it goes. There are definitely two groups on whether the
rest of this code goes into the kernel or into a library.
Mode setting on dual head cards means you also have to deal with memory
management. Changing the mode can cause the buffers to resize. Setting
a mode is useless without a buffer to display from so you have to deal
with this problem. fbdev has avoided this issue by only supporting a
single head.
But now introduce OpenGL. OpenGL supports double buffering with page
flipping on each display. It needs depth buffers, aux buffers, texture
memory etc. If you go full screen on a video you may want to switch to
a different framebuffer. OpenGl can discard and move these buffers too.
These are just some of the things that need to be considered when
designing the mode setting code. I haven't even touched on the boot
display and kernel printk. From what I know, mode setting is going to
be the hardest API to design.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Tue Jul 6 21:50:55 2004
Subject: [Xorg] Migration to tla?
Hi all,
This only concerns the xlibs repository right now. Before you go
screaming about X.Org, please note that I don't have designs on your
repository.
Yet. :)
I've been using tla for a while now, and having to move around, do
imports from the monolithic tree, do branching, etc, etc, made me
realise how much CVS sucks. As well as the changeset problem,
moving/renaming files, binary files, branching, etc. I finally snapped
when I looked at Roland's 'merge two branches' question, and wanted to
scream out 'tla star-merge!'.
So, I plan to do further xlibs development beyond a point in tla. All my
debrix development will be done in tla once I get it imported into arch,
which shouldn't take long at all. There are only two active debrix
contributors right now, but there are a couple more to xlibs (sort of
...).
What does anyone who actively/regularly commits to xlibs think about
moving to tla? I envision an all-tla repository, with a unidirectional
CVS gateway, so people using anoncvs can still check it out. This is
what will happen for debrix; if there is too much consternation for
xlibs, I will simply do all my development in tla, and have this gated
to the CVS tree (which sucks, but there you go).
tla offers the following advantages:
* Anyone can create their own branch off anything, without
having an account.
* You can then merge this -- history intact, but with a revision
note about having merged from a given branch -- with one
command: tla star-merge.
* You can pick and choose what you want; merging patches as
discrete units is far, far easier if you're using tla right.
* GnuPG signing support.
* True changesets are pretty invaluable.
* No need to have people SSHing into commit; simply have one
master branch, and star-merge into that.
* A lot more flexibility and granularity than CVS.
* The ability to keep our history/branches intact when we move.
* Sanity.
I am more than happy to help any xlibs hacker who wants to start using
tla to make the jump.
Are there any concerns? I ask only because I noted that xlibs-commit, of
late, has been almost all me, and having to use CVS is hindering my work
massively.
Cheers!
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/7edea9eb/attach
ment.pgp
Date: Tue Jul 6 22:35:11 2004
Subject: [Xorg] XDrawArc
In-Reply-To: Your message of "Tue, 06 Jul 2004 23:37:27 -0300."
<BAY1-F33ZhNfv57kVwy00003329@hotmail.com>
Message-ID: <E1Bi55A-00028Z-Op@evo.keithp.com>
Around 23 o'clock on Jul 6, "Francisco Afonso" wrote:
> I have some questions about XDrawArc:
You're brave for even attempting to use it...
> a) What maximum values are accepted for origin coordinates and diameter?
The representation of coordinates and bounding box is limited to 16 bits,
signed in the case of coordinates and unsigned in the case of the bounding
box.
> b) Is it possible to crash the client/server for large values (e.g. stack
> overflow)?
No, the server should never crash. It may fail to draw anything if it
runs out of memory (in which case a BadAlloc should be returned). Any
crash should be considered a bug.
> c) Does it use recursion?
I've never implemented arcs using recursion; I can't think of any obvious
reason one would do so.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/9b82ba7b/attach
ment.pgp
Date: Tue Jul 6 22:42:27 2004
<20040707045053.GA12023@fooishbar.org>
Message-ID: <E1Bi5CC-0002A6-0R@evo.keithp.com>
I'd love to see some experimentation with alternate repository systems. I
was looking at monotone, but it has some really ugly bits. I don't think
subversion offers enough advantages over CVS to really make it worth
moving. I haven't played with tla yet, but I'd sure like to see it in
action.
However, I'd like to see a gradual migration instead of a sudden fit of
action.
Could you start with debrix and see how things go? Some of us continue to
use xlibs and haven't the time to deal with a massive repository migration
this month...
I suggest you bribe me with whiskey during OLS and see how far you get.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040706/1d0d8b42/attach
ment.pgp
Date: Tue Jul 6 22:48:21 2004
In-Reply-To: <E1Bi5CC-0002A6-0R@evo.keithp.com>
References: <20040707045053.GA12023@fooishbar.org>
<E1Bi5CC-0002A6-0R@evo.keithp.com>
On Tue, Jul 06, 2004 at 10:42:15PM -0700, Keith Packard wrote:
> I'd love to see some experimentation with alternate repository systems. I
> was looking at monotone, but it has some really ugly bits. I don't think
> subversion offers enough advantages over CVS to really make it worth
> moving. I haven't played with tla yet, but I'd sure like to see it in
> action.
It's a beautiful thing. :)
> However, I'd like to see a gradual migration instead of a sudden fit of
> action.
>
> Could you start with debrix and see how things go? Some of us continue to
> use xlibs and haven't the time to deal with a massive repository migration
> this month...
OK. My only problem is that very few people check out/hack on debrix:
it's really just myself and ajax. But I'll do that, and bribe you in a
fortnight.
> I suggest you bribe me with whiskey during OLS and see how far you get.
Ice cream! :)
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/2d6b3c9a/attach
ment.pgp
From spyderous at gentoo.org Wed Jul 7 00:02:20 2004
From: spyderous at gentoo.org (Donnie Berkholz)
Date: Wed Jul 7 00:01:51 2004
On Wed, 2004-07-07 at 00:50, Daniel Stone wrote:
> tla offers the following advantages:
What are the disadvantages?
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/dc86a2ca/attach
ment-0001.pgp
From daniel at freedesktop.org Wed Jul 7 00:05:20 2004
Date: Wed Jul 7 00:05:23 2004
In-Reply-To: <1089183740.11598.1.camel@localhost>
<1089183740.11598.1.camel@localhost>
On Wed, Jul 07, 2004 at 03:02:20AM -0400, Donnie Berkholz wrote:
> On Wed, 2004-07-07 at 00:50, Daniel Stone wrote:
> > tla offers the following advantages:
>
> What are the disadvantages?
The fact it's not CVS is both its biggest advantage, and its biggest
disadvantage. It means change.
That's about it, really.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/748b9f31/attach
ment.pgp
From keithp at keithp.com Wed Jul 7 00:40:36 2004
Date: Wed Jul 7 00:40:48 2004
In-Reply-To: Your message of "Wed, 07 Jul 2004 03:02:20 EDT."
<1089183740.11598.1.camel@localhost>
Message-ID: <E1Bi72i-0003GR-KW@evo.keithp.com>
Around 3 o'clock on Jul 7, Donnie Berkholz wrote:
> What are the disadvantages?
Mostly that it's not CVS -- once the repository moves from CVS, you can't
go back (and you probably can't go to any other SCM either).
You're effectively locked into TLA until someone writes a tool to migrate
a TLA repository to the next best thing.
This is the best reason not to move to subversion; it doesn't offer enough
of the things we want and yet still prevents us from moving to something
newer.
CVS is horrible, but everyone can import from it at least.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/ae6ca740/attach
ment.pgp
Date: Wed Jul 7 00:43:56 2004
In-Reply-To: <E1Bi72i-0003GR-KW@evo.keithp.com>
References: <1089183740.11598.1.camel@localhost>
<E1Bi72i-0003GR-KW@evo.keithp.com>
Message-ID: <20040707074354.GJ12023@fooishbar.org>
On Wed, Jul 07, 2004 at 12:40:36AM -0700, Keith Packard wrote:
> Around 3 o'clock on Jul 7, Donnie Berkholz wrote:
> > What are the disadvantages?
>
> Mostly that it's not CVS -- once the repository moves from CVS, you can't
> go back (and you probably can't go to any other SCM either).
>
> You're effectively locked into TLA until someone writes a tool to migrate
> a TLA repository to the next best thing.
>
> This is the best reason not to move to subversion; it doesn't offer enough
> of the things we want and yet still prevents us from moving to something
> newer.
>
> CVS is horrible, but everyone can import from it at least.
To be fair, TLA having the concept of changesets makes this a crapload
easier.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/e9517e98/attach
ment.pgp
From thomas at winischhofer.net Wed Jul 7 00:58:25 2004
Date: Wed Jul 7 01:00:51 2004
<16618.29108.552996.705856@hermes.local>
<16618.46402.119628.614393@hermes.local>
<1089157728.17838.52.camel@localhost>
Message-ID: <40EBAD21.1050106@winischhofer.net>
Michel D?nzer wrote:
> On Tue, 2004-07-06 at 16:20 +0200, Egbert Eich wrote:
>
>>Thomas Winischhofer writes:
>> >
>> > Well, in reality they don't have to. Looking at each others code has
>> > been done, is being done and will be done anyway. A bit more of
>> > cooperation between fbdev and X driver developers (if not identical)
>> > would minimize this "agony" (if any). And finally: fbdev drivers are
>>
>>There still is a little obstacle that is tied to the license of the
>>drivers. Kernel drivers are GPL.
I said "look at", not "copy". "Writing identical values to registers" is
certainly not violating the GPL.
Thomas
--
Thomas Winischhofer
Vienna/Austria
From eta at lclark.edu Wed Jul 7 01:39:28 2004
Date: Wed Jul 7 01:40:06 2004
<16618.37064.382589.401333@hermes.local>
<200407061218.05041.ajax@nwnk.net>
On Tue, 2004-07-06 at 09:17, Adam Jackson wrote:
> > <snip>
> > 1) The XFree86 loader: One should assume the OS can dynamically load and
> > link modules and that the OS knows more about this than the X server. In
> > the past when very low level handling of object modules changed the X
> > Server blew up spectacularly and required surgery to very arcane pieces
> > of code none of which would have been necessary if the underlying system
> > services had been used. I might add being able run a debugger on a
> > running process would appear to be a novel concept ;-)
>
> I have to agree. Right now we've got both a libc thunk layer and a
> reimplementation of libdl in the server, all for a marginal (and I hear,
> rarely realized) gain in module portability. I have trouble justifying that.

> I'm currently working at fixing the drivers so the libdl loader is usable
> again.
I was talking with a NetBSD guy about this at USENIX. He said he used
the module portability all the time (many vendors provide binaries
compiled for x86 Linux, and x86 NetBSD just is not going to get them),
and I realized that I often also copy drivers between my OSes. But we
don't need the XFree86 loader to do that -- the elf modules and the libc
layer should be sufficient. I think we should think seriously about how
much overhead it is to keep the existing libc wrapper while using an elf
loader so we can have working debugging. It probably isn't that bad.
--
From michel at daenzer.net Wed Jul 7 02:07:09 2004
Date: Wed Jul 7 02:07:16 2004
On Tue, 2004-07-06 at 20:28 -0700, Jon Smirl wrote:
> > One thing I'd like to see is a general reduction of code that runs in
> > the same address space as the 'scary' bits. Starting with the device
> > initialization and mode selection logic makes good sense as none of
> > that is particularily performance sensitive. This should give us
> > significant freedom of choice in implementation.
>
> Mode setting code is large. If you add up everything for the radeon it
> is about 100K. Parts of this need to be in the kernel. For example the
> Linux kernel has a well defined framework for I2C (used to retrieve
> DDC). The IOCTL that actually sets the mode bits into the registers
> should be in the kernel to remove the need for X to be root. But those
> two things add up to about 5K of code.
I've said it many times, I'll say it again: I consider this a myth. The
register values don't become magically secure just because the kernel
writes them to the hardware instead of a user process. A good part of
the mode setting code will always have to be privileged one way or the
other.
--
From eich at pdx.freedesktop.org Wed Jul 7 02:19:14 2004
Date: Wed Jul 7 02:23:20 2004
In-Reply-To: jdennis@redhat.com wrote on Tuesday,
6 July 2004 at 10:18:48 -0400
<16618.29108.552996.705856@hermes.local>
John Dennis writes:
> You should assume the kernel in conjunction with other low level system
> services such as ACPI have correctly enumerated and configured the PCI
> bus topology and that VGA routing is correct. Unlike the current
> implementation you should not write new values into PCI bridge registers
> or in any way alter the hardware subsystem behind the kernel's back. You
> should trust the kernel and cooperate with it. In the past the X server
> has been a rude user mode guest who thought it knew more than the kernel
> and as a consequence has machine checked (crashed) entire systems :-(
John,
you try to make people believe that the Xserver is constantly reconfiguring
PCI config space. In fact it does this only under very rare circumstances
- and we had to implement this as at the time we added multi head support
many BIOSes were incapable to handle multiple graphics devices correctly
and there was no Linux around that was able to validate the PCI config space.
In fact Im sure you will have to dig around a lot to come up with an example
where this actually happens. The only cases where I have seen this happening
over the last two or three years was with old and broken PCI cards or other
rather strange configurations.
Oh, you've raised a second issue: VGA routing: VGA routing is *required*
with a lot of graphics cards if you want to offer multihead support. If
you have an AGP and a PCI card and want to do multihead using both cards
there is no way around VGA routing on a lot of chipsets. You may say this
is not a very likely configuration today...
Egbert.
Date: Wed Jul 7 03:01:38 2004
6 July 2004 at 12:05:48 -0400
<16618.37064.382589.401333@hermes.local>
<20040706152214.GD32444@fooishbar.org>
John Dennis writes:
> On Tue, 2004-07-06 at 11:41, Matthieu Herrb wrote:
> > Is it possible to have OS independant binary modules with this loader?
>
> Is it possible to have OS independent binary modules in the first place
> when its the OS that is producing the binary module?
>
> Sometimes, but its clearly not a reliable mechanism and I would argue of
> dubious value as binaries are typically release engineered for specific
> targets.
It clearly has been the goal to avoid that.
Instead the plan was to make drivers independent of the underlying
platform and OS and to enable the driver developer to support all
platforms/OSes supported by the base system without requiring him
to know each of these.
This has been usful in the past:
- Vendors who chose to provide binary only modules were able to support
an entire platform by developing and building on only one target system.
- Individual developers have provided preliminary and test version
of drivers and were able to provide these for a range of OSes
without needing multiple build platforms. With the dl loader a
driver that Alan Hourihane has build on Linux and provided thru
his web page would no longer work for any of the BSDs.
As for the reliablility:
The X binary module is clearly platform (ie CPU type) dependent.
Apart form this it should be portable between OSes provided the
same platform is used as long as these OSes use the same ABI
specification converning function calling conventions.
Egbert.
Date: Wed Jul 7 04:17:37 2004
In-Reply-To: ajax@nwnk.net wrote on Tuesday, 6 July 2004 at 12:40:40 -0400
<200407061240.41575.ajax@nwnk.net>
Adam Jackson writes:
>
> I would posit, however, that OS-independence in drivers is a false economy.
> OSes are cheap, get a multi-boot rig and compile them all directly. Or use a

> cross-compiler. From the perspective of the graphics card manufacturer,
> you'd need to have the target platform around for testing anyway if you're
> going to declare it a supported platform.
Well, do we believe the average developer will set up multiple
OSes or set up cross compile environments to provide binaries
for all supported OSes? What about the non-free OSes we support?
>
> Finally, if all else fails, it may be possible to keep the old loader around
> specifically for obstreperous vendors who don't feel like adding another
> machine to the compile farm. This would need some hacking to make work - in
> my tests the two module loaders are _not_ cross-callable - but it should be
> doable.
>
That may be an option. Currently symbol names from the dll modules cannot
be exported to the internal loader.
I also would like to call for a careful evaluation of the situation.
Most of the people here belong to the Linux community so they probably
don't care.
However I would very much like to hear the opinions of those who use
other OSes as they may be deprived of the possibility of loading binary
only device drivers in the future.
Egbert.
Date: Wed Jul 7 04:22:26 2004
In-Reply-To: keith@tungstengraphics.com wrote on Tuesday,
6 July 2004 at 17:27:55 +0100
<200407061240.41575.ajax@nwnk.net>
<40EAD30B.3060000@tungstengraphics.com>
Keith Whitwell writes:
>
> Ugh. That would be the ugliest. If it goes, it should go completely.
>
> Note that most drivers nowadays include a kernel component, so OS-independent

Not true.
> modules in the userspace are pretty pointless.
>
> Does anyone test that these modules actually can be run on another O/S? Does

> anyone care if they can't? Does any vendor actually make use of this?
1. It has been tested.
2. That's what we should find out.
3. That's not the point. A ia32 xyzBSD user can go and get the linux driver
and it should work.
>
> If someone really cares about cross-platform drivers, the module loader in
> XFree86 isn't a great place to start. For starters, there's the kernel
> problem I mentioned, but also I have to question how useful OS-independence i
s
> if you don't also gain CPU-independence.
The kernel problem doesn't exist in the form you describe.
Most drivers still work well without a chipset specific kernel driver.
In fact on some OSes that we support there isn't even the possibility to load
a driver into the kernel.
Egbert.
Date: Wed Jul 7 06:07:17 2004
In-Reply-To: roland.mainz@nrubsig.org wrote on Wednesday,
7 July 2004 at 05:03:07 +0200
References: <40EB67EB.DA2674B2@nrubsig.org>
Roland Mainz writes:
>
> Hi!
>
> ----
>
> Does anyone here have a _simple_ script which can sync two CVS branches
> ? I'd like to breath live into an old branch and update it to "trunk",
> including the special attributes of files in the CVS (execute flag,
> binary flag etc.) ...
>
If you haven't tagged the version where both versions have 'forked'
there probably isn't a simple way. If you have created the branch
on the old CURRENT branch and you have tagged the version from which
you have merged last you may be able to update from this tag to the
tag in current which marks the final version and then continue
merging the diffs between the initial version on trunk and the current
version.
Egbert.
Date: Wed Jul 7 06:16:00 2004
6 July 2004 at 11:17:28 -0400
<16618.37064.382589.401333@hermes.local>
John Dennis writes:
> On Tue, 2004-07-06 at 07:45, Egbert Eich wrote:
> > When you are talking about kernel partition you tie yourself to a single
> > OS - not necessarily a single architecture. This is what worries me a littl
e
> > bit.
>
> What worries me and seems to be a design philosophy embedded in XFree86
> is that in an attempt to be OS agnostic it implicitly declared itself
> superior to the OS and attempted to supersede the OS. From my
> perspective this is a fundamentally flawed model that ignores what we've
> learned about the need to partition and layer responsibility in large
> scale computer systems.
>
John,
What you call a 'fundamentally flawed model' in your effords to bash
XFree86 and the people who contributed to it was a necessity at the
time the code was implemented.
At that time there was no kernel (neither Linux nor any other open
source kernel) that would offer the functionality that we required.
Egbert.
Date: Wed Jul 7 06:24:09 2004
In-Reply-To: keithp@keithp.com wrote on Tuesday, 6 July 2004 at 17:36:30 -0700
References: <1089157779.17840.54.camel@localhost>
<E1Bi0QI-0001Z5-WE@evo.keithp.com>
>
> Around 1 o'clock on Jul 7, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote:
>
> > I basically agree, let's not pretend a root daemon is all that much
> > better though. Either will probably be better in some aspects, worse in
> > others.
>
> I concur with this sentiment -- any code directly manipulating the device
> registers runs a reasonable risk of corrupting the machine state. This
> makes the X server or this proposed daemon equal in many ways to the
> kernel.
>
For HW access this is certainly true, but it also deosn't make the kernel
a better choice than user land.
On the other hand a sloppy written user land code will probably just
segfault while similar flaws in a kernel module may mess up your entire
system.
> One thing I'd like to see is a general reduction of code that runs in the
> same address space as the 'scary' bits. Starting with the device
> initialization and mode selection logic makes good sense as none of that is
> particularily performance sensitive. This should give us significant
> freedom of choice in implementation.
>From a security point of view it is certainly the correct apporach to
separate the scary parts from the rest of the Xserver.
Egbert.
Date: Wed Jul 7 06:26:23 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Tuesday,
6 July 2004 at 09:36:04 -0700
References: <1089123528.26698.25.camel@finch.boston.redhat.com>
Jon Smirl writes:
> --- John Dennis <jdennis@redhat.com> wrote:
> > bus topology and that VGA routing is correct. Unlike the current
>
>
> 1) disabling all VGA devices
> 2) setting one VGA device active and get the bus routed to it
> 3) retrieving the board's VBIOS ROM.
4. Obtain a mmappable address for the PCI address ranges.
>
> This allow a user space reset program (they have to be user space since
> they use VM86 mode) to disable all VGA devices, reset the card by
> running the ROM, reenable the orginal VGA device.
>
> #3 needs a special case. The kernel has to track which VGA device the
> BIOS left active. When an app asks for the VBIOS ROM from this device,
> you return the memory contents at C000:0. Some laptops compress the
> VBIOS image of the primary adapter and this is where the uncompressed
> version is stored. The kernel has to remember the boot device so that
> if someone changes the active VGA device we will still know which
> adapter the image at C000:0 belongs too.
Some comments:
1. POSTed BIOSes are not always located at 0xc0000. Embedded systems
have them at all sorts of different places.
2. If we want to use vm86 mode for POSTing we will have to map the
first 1MB anyway, therefore it should be possible to retrieve this
BIOS from user land without having to map the kernel. Also to
use a POSTed BIOS we also need to know the int vectors (and some
other data from the first 64MB).
Most systems without vm86 probably don't keep this data around
thus require reposting anyway.
3. Even on primary cards you sometimes would like to have a copy of
the unposted BIOS around.
Therefore it would suffice to have a way to obtain the (unposted)
PCI BIOS image.
Egbert.
Date: Wed Jul 7 06:27:08 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Tuesday,
6 July 2004 at 20:28:58 -0700
References: <E1Bi0QI-0001Z5-WE@evo.keithp.com>
Jon Smirl writes:
> Mode setting code is large. If you add up everything for the radeon it
> is about 100K. Parts of this need to be in the kernel. For example the
> Linux kernel has a well defined framework for I2C (used to retrieve
> DDC). The IOCTL that actually sets the mode bits into the registers
> should be in the kernel to remove the need for X to be root. But those
> two things add up to about 5K of code. The rest of this code is open to
> debate where it goes. There are definitely two groups on whether the
> rest of this code goes into the kernel or into a library.
The Linux kernel does. What about the other OSes?
Today many drivers run the BIOS to retreive DDC data.
All that takes place in userland.
>
> Mode setting on dual head cards means you also have to deal with memory
> management. Changing the mode can cause the buffers to resize. Setting
> a mode is useless without a buffer to display from so you have to deal
> with this problem. fbdev has avoided this issue by only supporting a
> single head.
>
> But now introduce OpenGL. OpenGL supports double buffering with page
> flipping on each display. It needs depth buffers, aux buffers, texture
> memory etc. If you go full screen on a video you may want to switch to
> a different framebuffer. OpenGl can discard and move these buffers too.
>
> These are just some of the things that need to be considered when
> designing the mode setting code. I haven't even touched on the boot
> display and kernel printk. From what I know, mode setting is going to
> be the hardest API to design.
>
Basic mode setting code does not have to deal with these issues.
They need to be implemented on top of it.
Egbert.
Date: Wed Jul 7 06:29:10 2004
In-Reply-To: thomas@winischhofer.net wrote on Wednesday,
7 July 2004 at 09:58:25 +0200
<16618.29108.552996.705856@hermes.local>
<16618.46402.119628.614393@hermes.local>
<1089157728.17838.52.camel@localhost>
<40EBAD21.1050106@winischhofer.net>
>
> I said "look at", not "copy". "Writing identical values to registers" is
> certainly not violating the GPL.
>
This is exactly the problem: It isn't clear to me (and others here
probably have the same problem) how far one can go. Register values
are not the only problem, it may be the order in which they are
written (which often is not trivial to get right) or some other algorithms
which when I have seen them I probably would implement in a similar way.
You probably know much more about these things than I do.
Egbert.
From alexander.gottwald at s1999.tu-chemnitz.de Wed Jul 7 06:29:32 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Wed Jul 7 06:29:35 2004
<16619.62786.869225.902850@xf11.fra.suse.de>
Message-ID: <Pine.LNX.4.58.0407071527170.18487@odoaker.hrz.tu-chemnitz.de>
On Wed, 7 Jul 2004, Egbert Eich wrote:
> Roland Mainz writes:
> >
> > Hi!
> >
> > ----
> >
> > Does anyone here have a _simple_ script which can sync two CVS branches
> > ? I'd like to breath live into an old branch and update it to "trunk",
> > including the special attributes of files in the CVS (execute flag,
> > binary flag etc.) ...
> >
>
> If you haven't tagged the version where both versions have 'forked'
> there probably isn't a simple way. If you have created the branch
> on the old CURRENT branch and you have tagged the version from which
> you have merged last you may be able to update from this tag to the
> tag in current which marks the final version and then continue
> merging the diffs between the initial version on trunk and the current
> version.
What about creating a new branch and rename it to the old? For cygwin we have
the same problem which I'm going to by branching from HEAD again and leave
the old CYGWIN branch dead (or move the branch tag to the new branch).
bye
ago
--
Alexander.Gottwald@s1999.tu-chemnitz.de
http://www.gotti.org ICQ: 126018723
Date: Wed Jul 7 06:33:43 2004
<16618.37064.382589.401333@hermes.local>
<16619.63311.203935.636915@xf11.fra.suse.de>
On Wed, Jul 07, 2004 at 03:14:55PM +0200, Egbert Eich wrote:
> What you call a 'fundamentally flawed model' in your effords to bash
> XFree86 and the people who contributed to it was a necessity at the
> time the code was implemented.
> At that time there was no kernel (neither Linux nor any other open
> source kernel) that would offer the functionality that we required.
Egbert,
Please realise that this is not a personal attack. If John hated you,
he'd probably say it. The reality is that I appreciate the conditions
under which the code was borrowed/created, and what happened, but come
2004, the model is - I agree - fundamentally flawed.
This is not a personal attack. It's a statement of purely technical
views based on current-day experiences and data.
If we can't have discussions like this, then I'm off to find another
forum to work on advancing X.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/a0119847/attach
ment.pgp
Date: Wed Jul 7 06:34:46 2004
<16619.55940.456062.637560@xf11.fra.suse.de>
On Wed, Jul 07, 2004 at 01:12:04PM +0200, Egbert Eich wrote:
> Adam Jackson writes:
> > I would posit, however, that OS-independence in drivers is a false economy.

> > OSes are cheap, get a multi-boot rig and compile them all directly. Or use
a
> > cross-compiler. From the perspective of the graphics card manufacturer,
> > you'd need to have the target platform around for testing anyway if you're
> > going to declare it a supported platform.
>
> Well, do we believe the average developer will set up multiple
> OSes or set up cross compile environments to provide binaries
> for all supported OSes? What about the non-free OSes we support?
I believe that most graphic card manufacturers are capable of doing
this.
> > Finally, if all else fails, it may be possible to keep the old loader aroun
d
> > specifically for obstreperous vendors who don't feel like adding another
> > machine to the compile farm. This would need some hacking to make work - i
n
> > my tests the two module loaders are _not_ cross-callable - but it should be

> > doable.
> >
> That may be an option. Currently symbol names from the dll modules cannot
> be exported to the internal loader.
Does that mean it cannot be done?
> I also would like to call for a careful evaluation of the situation.
> Most of the people here belong to the Linux community so they probably
> don't care.
No, this is not true (the not caring bit).
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/10d4c1aa/attach
ment.pgp
From elylevy-xserver at cs.huji.ac.il Wed Jul 7 07:33:15 2004
Date: Wed Jul 7 07:33:20 2004
what about SVN which is preety much like cvs
and would make the migration easier without loosing
history and the sort
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 7 Jul 2004, Daniel Stone wrote:
> On Wed, Jul 07, 2004 at 03:02:20AM -0400, Donnie Berkholz wrote:
> > On Wed, 2004-07-07 at 00:50, Daniel Stone wrote:
> > > tla offers the following advantages:
> >
> > What are the disadvantages?
>
> The fact it's not CVS is both its biggest advantage, and its biggest
> disadvantage. It means change.
>
> That's about it, really.
>
> --
> Daniel Stone <daniel@freedesktop.or
g>
> freedesktop.org: powering your desktop http://www.freedesktop.o
rg
>
From thomas at winischhofer.net Wed Jul 7 07:32:29 2004
Date: Wed Jul 7 07:34:47 2004
References: <16617.22371.859445.768739@hermes.local> <20040705162752.37964.qm
ail@web14925.mail.yahoo.com> <16618.29108.552996.705856@hermes.local>
<40EA7D52.1030903@winischhofer.net> <16618.46402.119628.614393@hermes.local>
<1089157728.17838.52.camel@localhost> <40EBAD21.1050106@winischhofer.net>
<16619.60555.649641.102484@xf11.fra.suse.de>
Message-ID: <40EC097D.9050902@winischhofer.net>
Egbert Eich wrote:
> Thomas Winischhofer writes:
> >
> > I said "look at", not "copy". "Writing identical values to registers" is
> > certainly not violating the GPL.
> >
>
> This is exactly the problem: It isn't clear to me (and others here
> probably have the same problem) how far one can go. Register values
> are not the only problem, it may be the order in which they are
> written (which often is not trivial to get right) or some other algorithms
> which when I have seen them I probably would implement in a similar way.
This is getting a little OT now... but anyway:
[Disclaimer: The following is quite simplified.]
None of this is covered by copyright. Only the *very* *implementation* is.
Algorithms or ideas are never subject to copyright (and hence the
license), but eventually patents (in those poor countries where this
idiocy has been incorporated in law).
See:
outb(0x3c4,0x11,0x0f)
is two things:
1) what you see (the letters, digits etc) is eventually subject to
copyright. (Copyright originally was intended for literature or music or
other works of art. The idea was to protect the author's creativity in
terms of language, expressions, or - in case of music - the melody = the
sequence of tones = the language of music.)
2) what it does (setting all i2c data and clock bits on sis chips :) -
never try this at home ;)) is eventually subject to software patents.
To be subject to copyright requires the code in question to be somewhat
non-trivial which in copyright law is called "creative" (otherwise there
would be a copyright on for()-loops using i as the loop iterator - or,
even worse, for every-day phases in any spoken language).
Writing values to registers (which translates more or less 1:1 to
assembly) is not "creative". You can't copyright code that writes 0x0f
to sequencer register 0x3c4 index 0x11 (especially when considering that
there is only one possible statement to do so).
If such code is covered by a calculation or a special algorithm that
writes the registers in a certain order, this very implementation (=what
you see) is copyright-ible. If you do the same, but in a different
implementation, it is no copyright infringement. Simple for()-loops
writing registers in order, reading the data from a CARD8-array is not
copyright-ible.
From a practical point of view: Make the code look as different as
possible. For us, getting sued is enough trouble, and winning or losing
is secondary. If you want to avoid anybody even getting ideas, the code
should look really different.
To make absolutely sure, use macros for even trivial statements. The
fact that the linux kernel, for example, uses outb(data,port) whereas X
uses outb(port,data), is a good start anyway ;)
And please: This is no invitation for copyright infringements ;)
> You probably know much more about these things than I do.
Well, my doctor degree in law is more or less the result from a thesis
on software patents.
German speaking people on this list are welcome to read this thesis (in
a shortened version) which is freely available on my website.
Thomas
--
Thomas Winischhofer
Vienna/Austria
Date: Wed Jul 7 08:12:33 2004
Message-ID: <20040707151232.GM12023@fooishbar.org>
On Wed, Jul 07, 2004 at 05:33:15PM +0300, Ely Levy wrote:
> what about SVN which is preety much like cvs
> and would make the migration easier without loosing
> history and the sort
Right, it's pretty much like CVS: so there's not much point switching to
it if we don't gain all the features that come from moving *away* from
CVS. Don't get me wrong, it's a great 'better CVS', but why migrate for
no reason?
I'm also concerned at the scalability issues it throws up, especially in
regard to BDB.
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040708/7a803b82/attach
ment.pgp
From jonsmirl at yahoo.com Wed Jul 7 08:31:57 2004
Date: Wed Jul 7 08:32:00 2004
--- Michel Dnzer <michel@daenzer.net> wrote:
> I've said it many times, I'll say it again: I consider this a myth.
> The register values don't become magically secure just because the
> kernel writes them to the hardware instead of a user process. A
> good part of the mode setting code will always have to be
> privileged one way or the other.
Security means that the API is protected from from compromising the
overall security of the system. System security does not require
preventing you from writing the wrong values into register as long as
we are sure that those values can't be used to compromise system
security. Call mode validation something else, it is not security.
You can't stop the user from hitting the monitor with a sledge hammer either.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Wed Jul 7 08:43:48 2004
<16619.61020.996072.477213@xf11.fra.suse.de>
Message-ID: <E1BiEa9-00075k-Eg@evo.keithp.com>
> For HW access this is certainly true, but it also deosn't make the kernel
> a better choice than user land.
Yes, that's exactly right. We need to treat any such code with the same
care one would treat the kernel itself, it's all essentially equivalent.
> On the other hand a sloppy written user land code will probably just
> segfault while similar flaws in a kernel module may mess up your entire
> system.
The contrarary is equally true; kernel mistakes often result in benign
(from the system perspective) oopses while user-level mistakes can easily
lock up the PCI bus. Touching device registers is like that; there's no
magic bullet here.
> From a security point of view it is certainly the correct apporach to
> separate the scary parts from the rest of the Xserver.
I think this should be our goal -- address space separation of the 'scary'
parts of the X server and a common sharable API to access them.
Security and stability are the goals here; a separate device configuration
mechanism should allow:
1) Automatic recovery from X server crashes
2) 'printk' support while X is running
3) Multi-seat X support
4) Support for other graphics systems (GL-solo in particular)
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/23c7b4d1/attach
ment.pgp
Date: Wed Jul 7 08:45:16 2004
> Some comments:
> 1. POSTed BIOSes are not always located at 0xc0000. Embedded systems
> have them at all sorts of different places.
> 2. If we want to use vm86 mode for POSTing we will have to map the
> first 1MB anyway, therefore it should be possible to retrieve this
> BIOS from user land without having to map the kernel. Also to
> use a POSTed BIOS we also need to know the int vectors (and some
> other data from the first 64MB).
> Most systems without vm86 probably don't keep this data around
> thus require reposting anyway.
> 3. Even on primary cards you sometimes would like to have a copy of
> the unposted BIOS around.
> Therefore it would suffice to have a way to obtain the (unposted)
> PCI BIOS image.
While trying to fix the radeonfb driver, BenH has run into some laptops
that take the system BIOS and VBIOS, put them into a single image,
compress it, and put it into a ROM. They can do this because the video
is build into the motherboard. I don't know how you are going to find
this without help from the system or using the C000:0 copy.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From roland.mainz at nrubsig.org Wed Jul 7 08:51:52 2004
Date: Wed Jul 7 08:52:06 2004
<16619.62786.869225.902850@xf11.fra.suse.de>
<Pine.LNX.4.58.0407071527170.18487@odoaker.hrz.tu-chemnitz.de>
Message-ID: <40EC1C18.A12CFEF0@nrubsig.org>
Alexander Gottwald wrote:
> > > Does anyone here have a _simple_ script which can sync two CVS branches
> > > ? I'd like to breath live into an old branch and update it to "trunk",
> > > including the special attributes of files in the CVS (execute flag,
> > > binary flag etc.) ...
> >
> > If you haven't tagged the version where both versions have 'forked'
> > there probably isn't a simple way. If you have created the branch
> > on the old CURRENT branch and you have tagged the version from which
> > you have merged last you may be able to update from this tag to the
> > tag in current which marks the final version and then continue
> > merging the diffs between the initial version on trunk and the current
> > version.
>
> What about creating a new branch and rename it to the old? For cygwin we have
> the same problem which I'm going to by branching from HEAD again and leave
> the old CYGWIN branch dead (or move the branch tag to the new branch).
Uhm... it is possible to _RENAME_ a branch ?! How ? How ? I thought this
is impossible...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Wed Jul 7 08:54:45 2004
Message-ID: <E1BiEkb-00077c-GG@evo.keithp.com>
Around 17 o'clock on Jul 7, Ely Levy wrote:
> what about SVN which is preety much like cvs
> and would make the migration easier without loosing
> history and the sort
Migrating to SVN costs the same as migrating to TLA, and doesn't support
nice things like off-line development. TLA provides mechanisms to
preserve history when importing from CVS (which I'm sure Daniel will use
...).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040707/8f09fe42/attach
ment.pgp
Date: Wed Jul 7 09:24:27 2004
On Wed, 2004-07-07 at 08:31 -0700, Jon Smirl wrote:
> --- Michel Dnzer <michel@daenzer.net> wrote:
> > I've said it many times, I'll say it again: I consider this a myth.
> > The register values don't become magically secure just because the
> > kernel writes them to the hardware instead of a user process. A
> > good part of the mode setting code will always have to be
> > privileged one way or the other.
>
> Security means that the API is protected from from compromising the
> overall security of the system. System security does not require
> preventing you from writing the wrong values into register as long as
> we are sure that those values can't be used to compromise system
> security. Call mode validation something else, it is not security.
I never said 'system security', did I, but call it safety if you will.
> You can't stop the user from hitting the monitor with a sledge hammer either.
True, but that's not quite the same thing as a random unprivileged
program (a worm, say) destroying the monitor (or the graphics card, or
other hardware)... I'm not sure the user would like that.
--
Date: Wed Jul 7 09:26:20 2004
In-Reply-To: <40EC1C18.A12CFEF0@nrubsig.org>
<16619.62786.869225.902850@xf11.fra.suse.de>
<40EC1C18.A12CFEF0@nrubsig.org>
On Wed, 7 Jul 2004, Roland Mainz wrote:
> Alexander Gottwald wrote:
> > What about creating a new branch and rename it to the old? For cygwin we hav
e
> > the same problem which I'm going to by branching from HEAD again and leave
> > the old CYGWIN branch dead (or move the branch tag to the new branch).
>
> Uhm... it is possible to _RENAME_ a branch ?! How ? How ? I thought this
> is impossible...
I thought of using cvs tag -F. But I think this makes the old branch unacessible
.
eg. using "cvs tag -b -F CYGWIN" on HEAD would create a new branch and moves the
name CYGWIN from the old branch to the new. I could also _think of_ editing the
branch name in the repository files.
bye
ago
--
From loc at toya.net.pl Wed Jul 7 10:07:59 2004
Date: Wed Jul 7 10:08:09 2004
In-Reply-To: <Pine.LNX.4.58.0407071818210.18487@odoaker.hrz.tu-chemnitz.de>
References: <40EB67EB.DA2674B2@nrubsig.org> <16619.62786.869225.902850@xf11.
fra.suse.de> <Pine.LNX.4.58.0407071527170.18487@odoaker.hrz.tu-chemnitz.de>
Message-ID: <40EC2DEF.9040107@toya.net.pl>
> On Wed, 7 Jul 2004, Roland Mainz wrote:
>
>>Alexander Gottwald wrote:
>>
>>>What about creating a new branch and rename it to the old? For cygwin we have
>>>the same problem which I'm going to by branching from HEAD again and leave
>>>the old CYGWIN branch dead (or move the branch tag to the new branch).
>>
>>Uhm... it is possible to _RENAME_ a branch ?! How ? How ? I thought this
>>is impossible...
>
> I thought of using cvs tag -F. But I think this makes the old branch unacessib
le.
It would remain accessible by revision numbers I think.
--
Regards,
Jakub Piotr C?apa
From ajax at nwnk.net Wed Jul 7 10:12:05 2004
Date: Wed Jul 7 10:12:22 2004
<200407061240.41575.ajax@nwnk.net>
<16619.55940.456062.637560@xf11.fra.suse.de>
Hash: SHA1
On Wednesday 07 July 2004 07:12, Egbert Eich wrote:
> Adam Jackson writes:
> > I would posit, however, that OS-independence in drivers is a false
> > economy. OSes are cheap, get a multi-boot rig and compile them all
> > directly. Or use a cross-compiler. From the perspective of the
> > graphics card manufacturer, you'd need to have the target platform
> > around for testing anyway if you're going to declare it a supported
> > platform.
>
> Well, do we believe the average developer will set up multiple
> OSes or set up cross compile environments to provide binaries
> for all supported OSes?
Who's your average developer? If it's an OSS dev, then binary compatibility
(almost always a hack) isn't relevant, because the user has source
compatibility, and they can build their own native modules. If your average
developer is a distribution release engineer, then they already have either
native or cross-compilation facilities for all their supported platforms.
I'd also point out that sourceforge (for example) has devel machines for many
of the common platforms, and that fd.o could easily set up cross-compilers...
The only people who might suffer - maybe - would be graphics companies
releasing closed drivers. But let's dissect that assumption. All the
MetroLink loader really buys you, over the libdl loader, is module
portability between platforms with different executable formats. No, really.
The libc wrapper (which I'm not really opposed to) already insulates you from
the system libc. You've already assumed a processor. The only free variable
left is whether you can open the module using the system libdl.
Which leads me to...
> What about the non-free OSes we support?
What about them? I was unaware that _any_ Unix vendor's X server used the
MetroLink loader, so it's not like we can use modules from Xsun with
xorg-solaris. If this assumption is false I'd be very interested to know.
Going the other direction, the only closed MetroLink modules that exist (that
I know of, again corrections welcomed) are for x86, and the only x86
platforms where we run directly on the hardware are: the BSDs, Linux,
Solaris/x86, old creaky SysV clones, and maybe OS/2. Of those, the ones that
are currently shipping overwhelmingly use ELF for their native module format.
So the ability to load non-native module formats doesn't buy you much,
because all the world is an ELF system.
Old systems can continue to use the old loader, and they'll be supported just
as well as they ever were. All of the code changes that have been made to
make the libdl modules work have been perfectly cross-compatible, meaning you
can build an old-style module with debrix-drivers-ati and it'll work just
fine.
The difference in building an old-style module versus a new-style one is
exactly equal to running ld instead of ar for the link stage. So - modulo
bugfixes [1] - every closed binary driver vendor can instantly ship native
modules just by adding three lines to the makefile. And vice versa;
old-style modules are so easy to generate that there's no excuse to not build
them.
Which is fine, for the old decrepit platforms. But the MetroLink loader
causes real problems for modern systems.
> I also would like to call for a careful evaluation of the situation.
> Most of the people here belong to the Linux community so they probably
> don't care.
It's not that I don't care. If I didn't care I'd have nuked the old loader
from debrix already. I have thought it through, and I don't see any major
problems with making the native loader the default, but I've been wrong
before so I'm willing to keep the old loader around as a backup.
Of course, any driver supplier who refuses to supply old-style modules after
this transition is just being willfully perverse and hostile to their
customers, but that's not news or anything.
> However I would very much like to hear the opinions of those who use
> other OSes as they may be deprived of the possibility of loading binary
> only device drivers in the future.
Once the old loader is formally dead and buried, maybe, but again I don't see
that happening for a while yet. Deprecated, yes, but not removed.
- - ajax
[1] - Any driver vendors who need help detangling their drivers to work with
the libdl loader, _please_ let me know. It's nearly always a trivial fix.
iD8DBQFA7C7lW4otUKDs0NMRAnbAAJ9ODUJQRrDsAZtgLoEZCqTUNeL3nACfXE5K
meOVcdOHgnsa/Ql9kI67e6s=
=N64i
From jbarnes at engr.sgi.com Wed Jul 7 10:25:07 2004
From: jbarnes at engr.sgi.com (Jesse Barnes)
Date: Wed Jul 7 10:27:35 2004
Message-ID: <200407071025.07089.jbarnes@engr.sgi.com>
On Tuesday, July 6, 2004 9:36 am, Jon Smirl wrote:
> > bus topology and that VGA routing is correct. Unlike the current
>
>
> 1) disabling all VGA devices
> 2) setting one VGA device active and get the bus routed to it
This is possible, but also points out a deficiency in the current X server's
idea of I/O ports. I spoke with John Dennis about this a few weeks ago, but
it seems to me that we should either:
o make the in/out routines take full pointers for the port address value
- or -
o pass a PCI tag to them so that the platform code can figure out where to
route the I/O
As it stands, the X server's platform code has to assume one, global, I/O port
base address...
Jesse
From alan at lxorguk.ukuu.org.uk Wed Jul 7 10:07:12 2004
Date: Wed Jul 7 11:10:03 2004
<40E9CF97.8080301@xs4all.nl>
On Maw, 2004-07-06 at 02:57, Gene Heskett wrote:
> have 8 megs of ram, but the only limit I've seen is several folks
> have posted that it can only access 4 megs of it from that chipset.
Sort of. The 2D engine has a 4Mbyte limit but the other 4Mbytes can
be used for texture ram with the 3d driver patches (not that they
actually get textures right yet.. 8))
Date: Wed Jul 7 11:13:05 2004
On Llu, 2004-07-05 at 17:27, Jon Smirl wrote:
> But now we end up building everything twice on Linux since fbdev needs
> all of these things too. Then we have to spend time making the X and
> fbdev versions play nice together. Plus, X's PCI bus manipulations are
> in direct conflict with the Linux kernel.
The more can be pushed to user space the easier that gets. BTW I've been
looking at the PCI issue and there seems to be another lurking horror
which could cause corruption on big AMD64 boxes and in some other cases.
The BIOS emulation stuff (unless I've missed something
here which is possible as its a first scan) doesn't seem to revector
BIOS PCI conf1 access attempts via the kernel pci interface.
Date: Wed Jul 7 11:21:29 2004
In-Reply-To: <20040707133444.GL12023@fooishbar.org>
<200407061240.41575.ajax@nwnk.net>
<16619.55940.456062.637560@xf11.fra.suse.de>
<20040707133444.GL12023@fooishbar.org>
On Mer, 2004-07-07 at 14:34, Daniel Stone wrote:
> > for all supported OSes? What about the non-free OSes we support?
>
> I believe that most graphic card manufacturers are capable of doing
> this.
Capable but will they ? I suspect the answer is no. That is one reason
for keeping some kind of loader compatibility around (or figuring out if
you can load a linux-elf module on netbsd, given the gnu binutils
can do this kind of stuff like cross linking)
Date: Wed Jul 7 11:47:42 2004
<16619.62786.869225.902850@xf11.fra.suse.de>
Message-ID: <40EC4522.64A91E9@nrubsig.org>
> > > What about creating a new branch and rename it to the old? For cygwin we h
ave
> > > the same problem which I'm going to by branching from HEAD again and leave
> > > the old CYGWIN branch dead (or move the branch tag to the new branch).
> >
> > Uhm... it is possible to _RENAME_ a branch ?! How ? How ? I thought this
> > is impossible...
>
> I thought of using cvs tag -F. But I think this makes the old branch unacessib
le.
AFAIK it should still be possible to access the old tree via
pull-by-date.

> eg. using "cvs tag -b -F CYGWIN" on HEAD would create a new branch and moves t
he
> name CYGWIN from the old branch to the new.
Are there any known sideeffects of using "cvs tag -b -F FOOBAR" ?
> I could also _think of_ editing the
> branch name in the repository files.
That would be the last option... it sounds like conjuring satan to help
with rebuilding a cathedral... =:-)
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From alexdeucher at gmail.com Wed Jul 7 12:09:35 2004
Date: Wed Jul 7 12:09:38 2004
<40E9CF97.8080301@xs4all.nl>
Message-ID: <a728f9f904070712097522297e@mail.gmail.com>
On Wed, 07 Jul 2004 18:07:12 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2004-07-06 at 02:57, Gene Heskett wrote:
> > have 8 megs of ram, but the only limit I've seen is several folks
> > have posted that it can only access 4 megs of it from that chipset.
>
> Sort of. The 2D engine has a 4Mbyte limit but the other 4Mbytes can
> be used for texture ram with the 3d driver patches (not that they
> actually get textures right yet.. 8))
BTW, where are you or Eric's sis patches? Just curious...
Alex
Date: Wed Jul 7 16:35:27 2004
Subject: [Xorg] Multi-user systems
Here's a real reason to make multi-user work...
Kracs writes "HP are supplying their low-cost multi-user 441 desktops
to African schools. Running Mandrake Linux, and sporting four screens
(1xTNT2 AGP, 3xTNT2 PCI), keyboards and mice (1 PS2 set, 3 USB sets)
they provide relatively cheap computer access for up to four users (of
particular interest to schools in low economic zones). However,
according to this article on New Zealand's Xtra news page they've only
manufactured enough to outfit schools in South Africa. HP has commented
that they're talking to several organisations and are hoping to bring
the PC to market in other regions but have stated they will only be
marketed to developing countries." (Remember, there are also home-grown
methods to achieve similar results.)
http://slashdot.org/article.pl?sid=04/07/07/0217255&mode=nested&tid=147&tid=187
http://xtramsn.co.nz/news/0,,3782-3495250,00.html
http://h40058.www4.hp.com/products/desktops/441/prod_info.html
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From svetljo at gmx.de Wed Jul 7 16:55:21 2004
From: svetljo at gmx.de (Svetoslav Slavtchev)
Date: Wed Jul 7 16:55:55 2004
Subject: [Xorg] Multi-user systems
Message-ID: <3359.1089244521@www56.gmx.net>
> Here's a real reason to make multi-user work...
>
> Kracs writes "HP are supplying their low-cost multi-user 441 desktops
> to African schools. Running Mandrake Linux, and sporting four screens
> (1xTNT2 AGP, 3xTNT2 PCI), keyboards and mice (1 PS2 set, 3 USB sets)
> they provide relatively cheap computer access for up to four users (of
> particular interest to schools in low economic zones). However,
> according to this article on New Zealand's Xtra news page they've only
> manufactured enough to outfit schools in South Africa. HP has commented
> that they're talking to several organisations and are hoping to bring
> the PC to market in other regions but have stated they will only be
> marketed to developing countries." (Remember, there are also home-grown
> methods to achieve similar results.)
>
>
http://slashdot.org/article.pl?sid=04/07/07/0217255&mode=nested&tid=147&tid=187
> http://xtramsn.co.nz/news/0,,3782-3495250,00.html
> http://h40058.www4.hp.com/products/desktops/441/prod_info.html
:-)
have someone missed my request to merge a patch included in
Mandrake cooker & Debian sarge ?
it would be really nice if you could include it, till the other
big changes take
place
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/xorg-x11/Xorg-6.7.0-isolate
_device.patch?rev=1.1&content-type=text/x-cvsweb-markup
some more related links :
The Linux Console Project
http://linuxconsole.sourceforge.net
The Backstreet Ruby home page
http://startx.times.lv/
a HOWTO by me
http://tldp.org/HOWTO/XFree-Local-multi-user-HOWTO/
best,
svetljo
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
Date: Wed Jul 7 18:41:53 2004
<16619.55940.456062.637560@xf11.fra.suse.de>
<20040707133444.GL12023@fooishbar.org>
Message-ID: <20040708014151.GN12023@fooishbar.org>
On Wed, Jul 07, 2004 at 06:18:40PM +0100, Alan Cox wrote:
> On Mer, 2004-07-07 at 14:34, Daniel Stone wrote:
> > > for all supported OSes? What about the non-free OSes we support?
> >
> > I believe that most graphic card manufacturers are capable of doing
> > this.
>
> Capable but will they ? I suspect the answer is no. That is one reason
> for keeping some kind of loader compatibility around (or figuring out if
> you can load a linux-elf module on netbsd, given the gnu binutils
> can do this kind of stuff like cross linking)
True. There's also stuff like objcopy, but let's face it, they're more
likely to get bitten by carelessly linking to system libs that will end
up radically different, than end up being disappointed by us.
That said, it's not an argument against the functionality. If we can
keep it around, huzzah! If not, then we just have to look at whether the
price of the MetroLink loader outweighs the benefits of cross-OS
compatibility. (And before anyone pulls any of this 'other OS' stuff on
me, take a look at how well the MetroLink loader supports ia64, hppa,
and other such platforms. Go on, I dare you.)
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040708/dcaefb3c/attach
ment.pgp
From sand at blarg.net Wed Jul 7 21:10:21 2004
From: sand at blarg.net (sand@blarg.net)
Date: Wed Jul 7 21:10:19 2004
Subject: [Xorg] Xt 0.1.5 support for buttons 6 & 7
Message-ID: <16620.51501.868790.245842@priss.frightenedpiglet.com>
Back in June, Carlos Romero mentioned that he would soon commit a
patch to support buttons 6 and 7 in the XServer tree (although he
seems to have forgotten about it, based on the CVS repository):
http://freedesktop.org/pipermail/xorg/2004-June/000826.html
Two levels up, Xt 0.1.5 is also missing support for buttons 6 and 7.
I'd like to use them for CLIPBOARD copy and paste in xterm, so I've
written a patch against libXt-0.1.5 and xproto-6.6.2 to support them.
When I compile xterm-191 against the resulting libraries (on XFree86
4.3.0) it works as expected: I can create working translation bindings
for them in my X resources.
What's the next/first step in getting this fix applied to the
X Libraries sources?
Thanks,
Derek
--
Derek Upham
sand@blarg.net
"Ha! Your Leaping Tiger Kung Fu is no match for my Frightened Piglet style!"
Date: Wed Jul 7 21:13:19 2004
In-Reply-To: <16620.51501.868790.245842@priss.frightenedpiglet.com>
References: <16620.51501.868790.245842@priss.frightenedpiglet.com>
On Wed, Jul 07, 2004 at 09:10:21PM -0700, sand@blarg.net wrote:
> Back in June, Carlos Romero mentioned that he would soon commit a
> patch to support buttons 6 and 7 in the XServer tree (although he
> seems to have forgotten about it, based on the CVS repository):
>
> http://freedesktop.org/pipermail/xorg/2004-June/000826.html
>
> Two levels up, Xt 0.1.5 is also missing support for buttons 6 and 7.
> I'd like to use them for CLIPBOARD copy and paste in xterm, so I've
> written a patch against libXt-0.1.5 and xproto-6.6.2 to support them.
> When I compile xterm-191 against the resulting libraries (on XFree86
> 4.3.0) it works as expected: I can create working translation bindings
> for them in my X resources.
>
> What's the next/first step in getting this fix applied to the
> X Libraries sources?
Step one is to post the patch to the list ...
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040708/eb47f898/attach
ment.pgp
From elylevy-xserver at cs.huji.ac.il Thu Jul 8 03:33:06 2004
Date: Thu Jul 8 03:33:10 2004
Subject: [Xorg] small fix for xcompmgr
it seems tz does some problems,
(and is marked abosolete),
and since it is not used anyhow..
Ely Levy
System group
Hebrew University
Jerusalem Israel
-------------- next part --------------
Index: xcompmgr.c
===================================================================
RCS file: /cvs/xapps/xcompmgr/xcompmgr.c,v
diff -u -r1.23 xcompmgr.c
--- xcompmgr.c 8 Jul 2004 07:07:26 -0000 1.23
+++ xcompmgr.c 8 Jul 2004 10:30:51 -0000
@@ -164,9 +164,8 @@
get_time_in_milliseconds ()
{
struct timeval tv;
- struct timezone tz;

- gettimeofday (&tv, &tz);
+ gettimeofday (&tv, NULL);
return tv.tv_sec * 1000 + tv.tv_usec / 1000;
}

From sand at blarg.net Thu Jul 8 07:23:20 2004
Date: Thu Jul 8 07:23:19 2004
In-Reply-To: <20040708041317.GR12023@fooishbar.org>
<20040708041317.GR12023@fooishbar.org>
> On Wed, Jul 07, 2004 at 09:10:21PM -0700, sand@blarg.net wrote:
> > Two levels up, Xt 0.1.5 is also missing support for buttons 6 and 7.
> > I'd like to use them for CLIPBOARD copy and paste in xterm, so I've
> > written a patch against libXt-0.1.5 and xproto-6.6.2 to support them.
> > When I compile xterm-191 against the resulting libraries (on XFree86
> > 4.3.0) it works as expected: I can create working translation bindings
> > for them in my X resources.
>
> Step one is to post the patch to the list ...
>
Some groups are okay with patches against a specific distributed
version; others prefer patches against CVS. I've stuck patches
against the current TAR bundles to the bottom of this message.
One thing that we might want to change is the first patch block for
"X.h". I added the Button6MotionMask and Button7MotionMask entries to
the bottom of the *Mask list, in case shuffling the bit values of
the existing entries would break something. If that's not a risk,
then all the Button?MotionMask values would be better off together.
Derek
--
Derek Upham
sand@blarg.net
------------------------------ cut here ------------------------------
diff -u -r xproto-6.6.2.orig/X.h xproto-6.6.2/X.h
--- xproto-6.6.2.orig/X.h 2003-07-18 08:53:24.000000000 -0700
+++ xproto-6.6.2/X.h 2004-07-06 21:18:37.000000000 -0700
@@ -178,6 +178,8 @@
#define PropertyChangeMask (1L<<22)
#define ColormapChangeMask (1L<<23)
#define OwnerGrabButtonMask (1L<<24)
+#define Button6MotionMask (1L<<25)
+#define Button7MotionMask (1L<<26)

/* Event names. Used in "type" field in XEvent structures. Not to be
confused with event masks above. They start from 2 because 0 and 1
@@ -252,6 +254,8 @@
#define Button3Mask (1<<10)
+#define Button6Mask (1<<13)
+#define Button7Mask (1<<14)

#define AnyModifier (1<<15) /* used in GrabButton, GrabKey */

@@ -265,6 +269,8 @@
#define Button3 3
#define Button4 4
#define Button5 5
+#define Button6 6
+#define Button7 7

/* Notify modes */

diff -u -r libXt-0.1.5.orig/Event.c libXt-0.1.5/Event.c
--- libXt-0.1.5.orig/Event.c 2003-04-21 09:34:27.000000000 -0700
+++ libXt-0.1.5/Event.c 2004-07-06 20:17:41.000000000 -0700
@@ -766,7 +766,8 @@
static void CompressExposures();

#define KnownButtons (Button1MotionMask|Button2MotionMask|Button3MotionMask|\
- Button4MotionMask|Button5MotionMask)
+ Button4MotionMask|Button5MotionMask|Button6MotionMask|\
+ Button7MotionMask)

/* keep this SMALL to avoid blowing stack cache! */
/* because some compilers allocate all local locals on procedure entry */
diff -u -r libXt-0.1.5.orig/Pointer.c libXt-0.1.5/Pointer.c
--- libXt-0.1.5.orig/Pointer.c 2001-12-14 11:56:27.000000000 -0800
+++ libXt-0.1.5/Pointer.c 2004-07-06 20:19:09.000000000 -0700
@@ -54,7 +54,9 @@
#include "PassivGraI.h"

-#define AllButtonsMask (Button1Mask | Button2Mask | Button3Mask | Button4Mask |
Button5Mask)
+#define AllButtonsMask (Button1Mask | Button2Mask | Button3Mask | \
+ Button4Mask | Button5Mask | \
+ Button6Mask | Button7Mask)

Widget _XtProcessPointerEvent(event, widget, pdi)
XButtonEvent *event;
diff -u -r libXt-0.1.5.orig/TMparse.c libXt-0.1.5/TMparse.c
--- libXt-0.1.5.orig/TMparse.c 2003-05-27 15:26:43.000000000 -0700
+++ libXt-0.1.5/TMparse.c 2004-07-06 20:21:45.000000000 -0700
@@ -149,6 +149,8 @@
{"Button3", 0, ParseModImmed,Button3Mask},
+ {"Button6", 0, ParseModImmed,Button6Mask},
+ {"Button7", 0, ParseModImmed,Button7Mask},
{"c", 0, ParseModImmed,ControlMask},
{"s", 0, ParseModImmed,ShiftMask},
{"l", 0, ParseModImmed,LockMask},
@@ -160,6 +162,8 @@
{"Button3", 0, Button3},
+ {"Button6", 0, Button6},
+ {"Button7", 0, Button7},
{NULL, NULLQUARK, 0},
};

@@ -245,6 +249,8 @@
{"Btn3Down", NULLQUARK, ButtonPress, ParseImmed,(Opaque)Button3},
+{"Btn6Down", NULLQUARK, ButtonPress, ParseImmed,(Opaque)Button6},
+{"Btn7Down", NULLQUARK, ButtonPress, ParseImmed,(Opaque)Button7},

/* Event Name, Quark, Event Type, Detail Parser, Closure */

@@ -255,6 +261,8 @@
{"Btn3Up", NULLQUARK, ButtonRelease, ParseImmed,(Opaque)Button3},
+{"Btn6Up", NULLQUARK, ButtonRelease, ParseImmed,(Opaque)Button6},
+{"Btn7Up", NULLQUARK, ButtonRelease, ParseImmed,(Opaque)Button7},

{"MotionNotify", NULLQUARK, MotionNotify, ParseTable, (Opaque)motionDetails}
,
{"PtrMoved", NULLQUARK, MotionNotify, ParseTable, (Opaque)motionDetails},
@@ -266,6 +274,8 @@
{"Btn3Motion", NULLQUARK, MotionNotify, ParseAddModifier, (Opaque)Button3Mask},
+{"Btn6Motion", NULLQUARK, MotionNotify, ParseAddModifier, (Opaque)Button6Mask},
+{"Btn7Motion", NULLQUARK, MotionNotify, ParseAddModifier, (Opaque)Button7Mask},

{"EnterNotify", NULLQUARK, EnterNotify, ParseTable,(Opaque)notifyModes},
{"Enter", NULLQUARK, EnterNotify, ParseTable,(Opaque)notifyModes},
@@ -1097,7 +1107,8 @@
}

static ModifierMask buttonModifierMasks[] = {
- 0, Button1Mask, Button2Mask, Button3Mask, Button4Mask, Button5Mask
+ 0, Button1Mask, Button2Mask, Button3Mask, Button4Mask, Button5Mask,
+ Button6Mask, Button7Mask
};
static String ParseRepeat();

diff -u -r libXt-0.1.5.orig/TMprint.c libXt-0.1.5/TMprint.c
--- libXt-0.1.5.orig/TMprint.c 2003-04-21 09:34:29.000000000 -0700
+++ libXt-0.1.5/TMprint.c 2004-07-06 20:22:47.000000000 -0700
@@ -136,6 +136,9 @@
CHECK_STR_OVERFLOW(sb);
PRINTMOD(Button4Mask, "Button4");
PRINTMOD(Button5Mask, "Button5");
+ CHECK_STR_OVERFLOW(sb);
+ PRINTMOD(Button6Mask, "Button6");
+ PRINTMOD(Button7Mask, "Button7");

#undef PRINTMOD
}
diff -u -r libXt-0.1.5.orig/TMstate.c libXt-0.1.5/TMstate.c
--- libXt-0.1.5.orig/TMstate.c 2003-04-21 09:34:29.000000000 -0700
+++ libXt-0.1.5/TMstate.c 2004-07-06 20:23:39.000000000 -0700
@@ -1183,7 +1183,8 @@
}
tempMask = modifierMask &
(Button1Mask | Button2Mask | Button3Mask
- | Button4Mask | Button5Mask);
+ | Button4Mask | Button5Mask | Button6Mask
+ | Button7Mask);
if (tempMask == 0)
return PointerMotionMask;
if (tempMask & Button1Mask)
@@ -1196,6 +1197,10 @@
returnMask |= Button4MotionMask;
if (tempMask & Button5Mask)
returnMask |= Button5MotionMask;
+ if (tempMask & Button6Mask)
+ returnMask |= Button6MotionMask;
+ if (tempMask & Button7Mask)
+ returnMask |= Button7MotionMask;
return returnMask;
}
returnMask = _XtConvertTypeToMask(eventType);
From keithp at keithp.com Thu Jul 8 09:52:07 2004
Date: Thu Jul 8 09:52:20 2004
In-Reply-To: Your message of "Thu, 08 Jul 2004 07:23:20 PDT."
<16621.22744.483401.786422@priss.frightenedpiglet.com>
Message-ID: <E1Bic7z-0001kx-D7@evo.keithp.com>
Around 7 o'clock on Jul 8, sand@blarg.net wrote:
> One thing that we might want to change is the first patch block for
> "X.h". I added the Button6MotionMask and Button7MotionMask entries to
> the bottom of the *Mask list, in case shuffling the bit values of
> the existing entries would break something.
You don't get to change X.h at all; you can't add new event masks to the
protocol (the X server would have to be changed to support them), and you
needn't add new Button? names. I'd add Xt specific button names instead
#define XtButton6 6
#define XtButton7 7
I don't know how hard it will be to get Xt to accept buttons for which no
event selection or state bits exist, but that's the only way to make this
work.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040708/6058ebbb/attach
ment-0001.pgp
From sandmann at daimi.au.dk Thu Jul 8 10:01:45 2004
From: sandmann at daimi.au.dk (Soeren Sandmann)
Date: Thu Jul 8 10:01:50 2004
Subject: [Xorg] Faster render with gcc 3.4 mmx intrinsics
Message-ID: <ye87jtewhza.fsf@ec02.daimi.au.dk>
On bug 839
there is a patch adding faster versions of some the render ops.
A benchmark rendering a paragraph of component alpha text to a pixmap
gave these results on a 1200 MHz laptop with an i830 chip running
Fedora Core I:
Unmodified X server and the pixmap in system RAM:
[ssp@localhost x]$ ./a.out
total time: 41.394618
average rect time: 0.683200
worst rect: 9
average glyph time: 3.550500
with the MMX optimizations:
worst rect: 9
Ie., text rendering is more than twice as fast. The 'average glyph
time' here is the time it takes to render the entire paragraph of
text.
With the pixmap in video RAM, the speedup is not quite as
spectacular:
Unmodified X server:
worst rect: 1
With MMXified compositing:
worst rect: 6
But still a nice improvement. The patch includes improved code for
these cases:
Subpixel text:
- (constant color) in (component alpha mask) over 565 destination
- (constant color) in (component alpha mask) over 32bit destination
- (32 bit component alpha) Saturate (32 bit destination)
Regular antialiased text:
- (8 bit alpha) Saturate (8 bit destination)
- (constant color) in (8 bit alpha mask) over 565 destination
- (constant color) in (8 bit alpha mask) over 32bit destination
GdkPixbuf:
- (reversed, non-premultiplied source) over 32bit destination
- (reversed, non-premultiplied source) over 565 destination
Alpha rectangle (e.g., Nautilus selection rectangle):
- (constant color) over 32bit destination
- (constant color) over 565 destination
Solid fill
- solid fill of 32 bit drawable
The code can optionally be compiled to use the pshufw instruction, which
is only available on pentium III.
One question: The patch has a bad hack where it redefines
DefaultCCOptions for all of the framebuffer code. How should this be
done properly? The problem with the existing DefaultCCOptions is that
they include -pedantic which doesn't work with the MMX intrinsics.
S?ren
From alan at lxorguk.ukuu.org.uk Thu Jul 8 14:18:26 2004
Date: Thu Jul 8 15:21:17 2004
In-Reply-To: <a728f9f904070712097522297e@mail.gmail.com>
<40E9CF97.8080301@xs4all.nl>
<a728f9f904070712097522297e@mail.gmail.com>
On Mer, 2004-07-07 at 20:09, Alex Deucher wrote:
> > Sort of. The 2D engine has a 4Mbyte limit but the other 4Mbytes can
> > be used for texture ram with the 3d driver patches (not that they
> > actually get textures right yet.. 8))
>
> BTW, where are you or Eric's sis patches? Just curious...
On my ftp site. I've got newer bits but I've been away most of this week
on a language course but I hope to merge it with the current tree soon.
From Alan.Coopersmith at Sun.COM Thu Jul 8 20:10:44 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Thu Jul 8 20:09:36 2004
<200407061240.41575.ajax@nwnk.net>
<16619.55940.456062.637560@xf11.fra.suse.de>
<200407071312.06968.ajax@nwnk.net>
Message-ID: <40EE0CB4.2030900@sun.com>
Adam Jackson wrote:
> What about them? I was unaware that _any_ Unix vendor's X server used the
> MetroLink loader, so it's not like we can use modules from Xsun with
> xorg-solaris. If this assumption is false I'd be very interested to know.
There is a bridge module we've made for Xsun to allow it to load modules using
the MetroLink loader, so that it can use XFree86/Xorg drivers, but it requires
recompiling the driver to work (Xsun & XFree86 structure layouts are not
compatible for some of the core X server structures), and is one way - you can't
load an Xsun module with it. (The native Xsun module loader is simply dlopen(),
but since Xsun & Xorg have different API's, you'ld have to provide some way to
deal with those calls in Xorg in order to be able to use an Xsun module, and I'm
not sure it's worth the effort to do all that.)
> Which is fine, for the old decrepit platforms. But the MetroLink loader
> causes real problems for modern systems.
That definitely matches our experiences here.
>>However I would very much like to hear the opinions of those who use
>>other OSes as they may be deprived of the possibility of loading binary
>>only device drivers in the future.
How many of those binary-only device drivers are truly platform-independent
and don't require special kernel modules or other platform-dependent bits?
(I admit, I've only tried the Nvidia binary driver - I don't know about any
others that may exist.)
--
-Alan Coopersmith- alan.coopersmith@sun.com
Sun Microsystems, Inc. - X Window System Engineering
From sandmann at daimi.au.dk Fri Jul 9 06:47:49 2004
Date: Fri Jul 9 06:48:03 2004
Subject: [Xorg] Faster render with gcc 3.4 mmx intrinsics
In-Reply-To: <ye87jtewhza.fsf@ec02.daimi.au.dk>
References: <ye87jtewhza.fsf@ec02.daimi.au.dk>
Message-ID: <ye8hdsh70my.fsf@ec02.daimi.au.dk>
Soeren Sandmann <sandmann@daimi.au.dk> writes:
> On bug 839
>
>
> there is a patch adding faster versions of some the render ops.
I have put up Fedora Core 2 RPMS at
http://www.freedesktop.org/~sandmann/rpms/
S?ren
From eger at havoc.gtf.org Fri Jul 9 07:12:12 2004
Date: Fri Jul 9 07:12:48 2004
Subject: [Xorg] why is it so hard to get specs?
Message-ID: <20040709141212.GB14434@havoc.gtf.org>
I'm curious:
Why don't ATI/Nvidia/etc. ever seem to want to release programming specs
for their chips or source code for their drivers?
Doesn't everyone benefit from peer review? These companies want to sell
chips, no? The graphics card makers don't actually sell drivers... :-/
Is there anything we as a community can do to encourage them to be more
forthcoming? Could someone working at some said company proffer an
honest answer?
-dte
From elanthis at awesomeplay.com Fri Jul 9 07:20:04 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Fri Jul 9 07:20:17 2004
In-Reply-To: <20040709141212.GB14434@havoc.gtf.org>
References: <20040709141212.GB14434@havoc.gtf.org>
Message-ID: <1089382803.32219.3.camel@support02.civic.twp.ypsilanti.mi.us>
On Fri, 2004-07-09 at 10:12, David Eger wrote:
> I'm curious:
>
> Why don't ATI/Nvidia/etc. ever seem to want to release programming specs
> for their chips or source code for their drivers?
This is a really old topic; the answer has been stated very many times
before in the list archives and elsewhere...
Long story short, they don't want competitors to know the interfaces to
their hardware, or because they license hardware components from third
parties, they are legally obligated not to release the hardware
interface information.
--
Sean Middleditch <elanthis@awesomeplay.com>
AwesomePlay Productions, Inc.
From dermot at dspsrv.com Fri Jul 9 07:22:40 2004
From: dermot at dspsrv.com (Dermot McGahon)
Date: Fri Jul 9 07:22:51 2004
In-Reply-To: <20040709141212.GB14434@havoc.gtf.org>
References: <20040709141212.GB14434@havoc.gtf.org>
Message-ID: <opsavjj21h3ertue@mail.dspsrv.com>
On Fri, 9 Jul 2004 10:12:12 -0400, David Eger <eger@havoc.gtf.org> wrote:
> Is there anything we as a community can do to encourage them to be more
> forthcoming? Could someone working at some said company proffer an
> honest answer?
David,
I don't work for one of the companies, but as far as I understand
the issue, it's about keeping expensively researched technology
secret for long enough to make money from it.
I think they are afraid that if they are very open with specs that
their h/w becomes reverse engineerable and thus open to copying
by: (a) competitors; (b) companies in the far east.
Hard to blame them really, if this is the case, but perhaps there
is more to it than that.
Dermot.
--
From jonsmirl at yahoo.com Fri Jul 9 07:43:59 2004
Date: Fri Jul 9 07:44:02 2004
In-Reply-To: <1089382803.32219.3.camel@support02.civic.twp.ypsilanti.mi.us>
Talking to some of the Nvidia/ATI people I would say it is more out of
fear of being sued for patent infrigement that it is a desire to keep
anything secret. Providing the specs provides documantation for someone
to sue them with. It's unintentional infringement they are worried
about, not intentional.
--- Sean Middleditch <elanthis@awesomeplay.com> wrote:
> On Fri, 2004-07-09 at 10:12, David Eger wrote:
> > I'm curious:
> >
> > Why don't ATI/Nvidia/etc. ever seem to want to release programming
> specs
> > for their chips or source code for their drivers?
>
> This is a really old topic; the answer has been stated very many
> times
> before in the list archives and elsewhere...
>
> Long story short, they don't want competitors to know the interfaces
> to
> their hardware, or because they license hardware components from
> third
> parties, they are legally obligated not to release the hardware
> interface information.
> --
> Sean Middleditch <elanthis@awesomeplay.com>
> AwesomePlay Productions, Inc.
>
>
> _______________________________________________
> xorg mailing list
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From anderson at netsweng.com Fri Jul 9 04:53:28 2004
From: anderson at netsweng.com (Stuart Anderson)
Date: Fri Jul 9 08:55:47 2004
In-Reply-To: <40EE0CB4.2030900@sun.com>
<200407061240.41575.ajax@nwnk.net>
<16619.55940.456062.637560@xf11.fra.suse.de>
<200407071312.06968.ajax@nwnk.net> <40EE0CB4.2030900@sun.com>
Message-ID: <Pine.LNX.4.58.0407090751240.1607@trantor.stuart.netsweng.com>
On Thu, 8 Jul 2004, Alan Coopersmith wrote:
> How many of those binary-only device drivers are truly platform-independent
> and don't require special kernel modules or other platform-dependent bits?
> (I admit, I've only tried the Nvidia binary driver - I don't know about any
> others that may exist.)
Roughly, all of them _execpt_ the Nvidia driver. 8-). All of the driver
that are part of the XFree86/Xorg tree should be binary portable, at
least for 2D stuff.
Stuart
Stuart R. Anderson anderson@netsweng.com
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
From carl at personnelware.com Fri Jul 9 09:02:08 2004
Date: Fri Jul 9 08:56:27 2004
Subject: [Xorg] i830_video.c: In function I830PutImage noPanoramiXExtension
undeclared
Message-ID: <25fb01c465ce$1661e800$1e01a8c0@cnt496>
Today's CVS (7/9) and playing with host.def gave me problems.
Carl K
$ perl -0777 -pe 's{/\*.*?\*/}{}gs' host.def | grep "#"
#define XF86CardDrivers fbdev XF86ExtraCardDrivers
#define XF86ExtraCardDrivers i810
#define XInputDrivers mouse keyboard microtouch
#define UseMatroxHal NO
#define Freetype2BuildDefines -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER
#define BuildXinerama NO
#define BuildIPv6 NO
$ make World
...
rm -f i830_video.o
gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wp
ointer-arith -Wundef -fno-merge-constants -I. -I../../../../../../programs/Xs
erver/hw/xfree86/common -I../../../../../../programs/Xserver/hw/xfree86/os-suppo
rt -I../../../../../../programs/Xserver/
mfb -I../../../../../../programs/Xserver/mi
-I../../../../../../programs/Xserver/hw/xfree86/xaa -I../../../../../../progra
ms/Xserver/hw/xfree86/rac -I../../../..
/../../programs/Xserver/miext/shadow
-I../../../../../../programs/Xserver/fb -I../../../../../../programs/Xserver/
hw/xfree86/xaa -I../../../../../../programs/Xserver/hw/xfree86/ramdac
-I../../../../../../programs/Xserver/hw/xfree86/vgahw -I../../../../../../prog
rams/Xserver/hw/xfree86/ddc -I../../../../../../programs/Xserver/hw/xfree86/i2c
-I../../../../../../programs/Xserver/hw/xfree86/vbe -I../../../../../../progra
ms/Xserver/hw/xfree86/int10 -I../../../../../../p
rograms/Xserver/hw/xfree86/shadowfb -I../
../../../../../programs/Xserver/Xext
-I../../../../../../include/fonts -I../../../../../../programs/Xserver
/include -I../../../../../../exports/include/X11 -I../../../..
/../../include/extensions -I../../../../../../programs/Xserver/render
-I../../../../../../programs/Xserver/GL/dri -I../../../../../../lib/GL/dri -
I../../../../../../include -I../../../../../../extras/drm/shared -I../../../../
../.. -I../../../../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE
=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -
D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BI
GFONT -DDPMSExtension -DPIXPRIV -DRENDER -DRANDR -DXFIXES -DDAMAG
E -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -
DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree
86Server -DXF86VIDMODE -
DXvMCExtension -DSMART_SCHEDULE -
DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_
ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7)
* 100000) + ((0) * 1000) +
)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DGLXEXT
-DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DI830_XV -D
XVENDORNAME='"The X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' -c
i830_video.c
i830_video.c: In function Ì830PutImage':
i830_video.c:1452: error: `noPanoramiXExtension' undeclared (first use in this
function)
i830_video.c:1452: error: (Each undeclared identifier is reported only once
i830_video.c:1452: error: for each function it appears in.)
i830_video.c: In function Ì830DisplaySurface':
function)
make[7]: *** [i830_video.o] Error 1
make[7]: Leaving directory
`/home/carl/src/xc/programs/Xserver/hw/xfree86/drivers/i810'
From ajax at nwnk.net Fri Jul 9 09:02:01 2004
Date: Fri Jul 9 09:02:07 2004
In-Reply-To: <Pine.LNX.4.58.0407090751240.1607@trantor.stuart.netsweng.com>
References: <16617.22371.859445.768739@hermes.local> <40EE0CB4.2030900@sun.com>
<Pine.LNX.4.58.0407090751240.1607@trantor.stuart.netsweng.com>
Hash: SHA1
On Friday 09 July 2004 07:53, Stuart Anderson wrote:
> On Thu, 8 Jul 2004, Alan Coopersmith wrote:
> > How many of those binary-only device drivers are truly
> > platform-independent and don't require special kernel modules or other
> > platform-dependent bits? (I admit, I've only tried the Nvidia binary
> > driver - I don't know about any others that may exist.)
>
> Roughly, all of them _execpt_ the Nvidia driver. 8-). All of the driver
> that are part of the XFree86/Xorg tree should be binary portable, at
> least for 2D stuff.
That's not the question though. The question is about binary-only device
drivers, the ones that aren't in the X tree.
Offhand, I believe the binary modules from ATI, Matrox, and PowerVR are
x86-only and have a kernel component, which makes them not
platform-independent.
- - ajax
iD8DBQFA7sF5W4otUKDs0NMRAovNAKCiFiKAKiETwGT96veVDN9TXkDG3wCeJIRy
ZxQPa4OccyKYc32EggWadUs=
=AkFD
From krahn at niehs.nih.gov Fri Jul 9 09:10:05 2004
Date: Fri Jul 9 09:10:42 2004
Message-ID: <40EEC35D.4000601@niehs.nih.gov>
Right. In other words, it all makes very little practical sense,
but is very straight forward to lawyers. Things are more treacherous
now with the huge number of software methods patents.
In general, if there are enough hardware users to make the release
of information profitable to them (the bottom line for any decision),
then it probably is better to pay internal developers to do the work
anyhow.
BUT, I think the internal driver development by ATI and Nvidia could
do much better with a public bug-tracking system. Maybe this would
make it too easy for competitors to say "look at all of their bugs".
Joe Krahn
Jon Smirl wrote:
> Talking to some of the Nvidia/ATI people I would say it is more out of
> fear of being sued for patent infrigement that it is a desire to keep
> anything secret. Providing the specs provides documantation for someone
> to sue them with. It's unintentional infringement they are worried
> about, not intentional.
>
> --- Sean Middleditch <elanthis@awesomeplay.com> wrote:
>
>>On Fri, 2004-07-09 at 10:12, David Eger wrote:
>>
>>>I'm curious:
>>>
>>>Why don't ATI/Nvidia/etc. ever seem to want to release programming
>>
>>specs
>>
>>>for their chips or source code for their drivers?
>>
>>This is a really old topic; the answer has been stated very many
>>times
>>before in the list archives and elsewhere...
>>
>>Long story short, they don't want competitors to know the interfaces
>>to
>>their hardware, or because they license hardware components from
>>third
>>parties, they are legally obligated not to release the hardware
>>interface information.
>>--
>>Sean Middleditch <elanthis@awesomeplay.com>
>>AwesomePlay Productions, Inc.
>>
>>
>>_______________________________________________
>>xorg mailing list
>>xorg@freedesktop.org
>>http://freedesktop.org/mailman/listinfo/xorg
>>
>
>
>
> =====
> Jon Smirl
>
>
>
> __________________________________
> Do you Yahoo!?
>
> _______________________________________________
> xorg mailing list
From ufz6 at rz.uni-karlsruhe.de Fri Jul 9 09:30:24 2004
Date: Fri Jul 9 09:27:58 2004
Subject: [Xorg] static winodw problem
Message-ID: <E1BiyE5-0007hp-00@mailgate.rz.uni-karlsruhe.de>
As I mentioned in early thread we use composite and damage extension (based
on yours) to set 3D effect on program. But it still in earlier version.
Our problem now, that sometime after closing a window ( for example mozilla)
part of the screen stay static (always at the left top of the screen). The
size of this static window is equal to the program we close.

I only want to where it could the problem. May be it is on composite
extension or the damage extension.
I work on this problem since a long time, but without success, because I
don't exactly the reason of this problem.

I will be glad to hear advisement from you !!

Amir
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040709/4237e05d/attachm
ent.htm
Date: Fri Jul 9 10:11:08 2004
Subject: [Xorg] optimal settings for i810
Message-ID: <268001c465d8$7ff4d6b0$1e01a8c0@cnt496>
If I have i810fb support built into the kernel - what should I use for
XF86CardDrivers?
my current pick:
#define XF86CardDrivers fbdev XF86ExtraCardDrivers
#define XF86ExtraCardDrivers i810
Carl K
From kem at freedesktop.org Fri Jul 9 10:54:48 2004
From: kem at freedesktop.org (Kevin E Martin)
Date: Fri Jul 9 10:54:52 2004
Subject: [Xorg] Next X.Org Foundation release plan
Message-ID: <20040709175448.GB18379@kem.org>
On today's release wranglers call, the group discussed plans for having
the next X.Org Foundation release by August 25th. The primary new
features planned for this release are three new extensions: Damage,
XFixes and Composite.
Some of the open questions are:
- What is the state of each of these extensions, and what additional
work is needed to complete their integration into the CVS repository?
- What other functionality should be integrated before the release?
- Is the DRI support up-to-date or are there additional bug fixes that
need to be applied to the tree?
- What other patches/bug fixes are needed?
- Other items and/or open questions?
The purpose of this e-mail is to get the discussing going on these and
any other issues related to the next release, so that during the next
release wranglers call, we can come to a consensus on the release plans.
From eta at lclark.edu Fri Jul 9 11:29:03 2004
Date: Fri Jul 9 11:29:38 2004
In-Reply-To: <20040709175448.GB18379@kem.org>
References: <20040709175448.GB18379@kem.org>
On Fri, 2004-07-09 at 10:54, Kevin E Martin wrote:
> On today's release wranglers call, the group discussed plans for having
> the next X.Org Foundation release by August 25th. The primary new
> features planned for this release are three new extensions: Damage,
> XFixes and Composite.
>
> Some of the open questions are:
>
> - What is the state of each of these extensions, and what additional
> work is needed to complete their integration into the CVS repository?
> - What other functionality should be integrated before the release?
> - Is the DRI support up-to-date or are there additional bug fixes that
> need to be applied to the tree?
> - What other patches/bug fixes are needed?
> - Other items and/or open questions?
AFAIK the damage/fixes bits are ready to go, but we'll want to test them
with Composite and all the damage/fixes-using programs that composite
allows. I've pushed "Doing Composite in xorg" up to the top of my TODO
list so I should have something soon.
We'll need to take a look at bugfixes to pull in from DRI/Mesa CVS. DRI
CVS has been destabilized somewhat by the TLS prep work that's happened,
but supposedly all the known issues (except for the sparc asm dispatch,
which can be just disabled) have been fixed. I'll look into what needs
to be brought in some time before release, but not in the next couple of
weeks. It would also be nice to get
http://freedesktop.org/bugzilla/show_bug.cgi?id=709 fixed as I'm
concerned about compatibility issues if it isn't.
--
From loc at toya.net.pl Fri Jul 9 11:52:43 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Fri Jul 9 11:52:57 2004
In-Reply-To: <1089397743.891.19.camel@leguin>
References: <20040709175448.GB18379@kem.org> <1089397743.891.19.camel@leguin>
Message-ID: <40EEE97B.1030105@toya.net.pl>
Eric Anholt wrote:
> On Fri, 2004-07-09 at 10:54, Kevin E Martin wrote:
>
>>On today's release wranglers call, the group discussed plans for having
>>the next X.Org Foundation release by August 25th. The primary new
>>features planned for this release are three new extensions: Damage,
>>XFixes and Composite.
>>
>>Some of the open questions are:
>>
>>- What is the state of each of these extensions, and what additional
>> work is needed to complete their integration into the CVS repository?
>>- What other functionality should be integrated before the release?
>>- Is the DRI support up-to-date or are there additional bug fixes that
>> need to be applied to the tree?
>>- What other patches/bug fixes are needed?
>>- Other items and/or open questions?
>
> AFAIK the damage/fixes bits are ready to go, but we'll want to test them
> with Composite and all the damage/fixes-using programs that composite
> allows. I've pushed "Doing Composite in xorg" up to the top of my TODO
> list so I should have something soon.
>
> We'll need to take a look at bugfixes to pull in from DRI/Mesa CVS. DRI
> CVS has been destabilized somewhat by the TLS prep work that's happened,
> but supposedly all the known issues (except for the sparc asm dispatch,
> which can be just disabled) have been fixed. I'll look into what needs
> to be brought in some time before release, but not in the next couple of
> weeks. It would also be nice to get
> http://freedesktop.org/bugzilla/show_bug.cgi?id=709 fixed as I'm
> concerned about compatibility issues if it isn't.
And where is debrix in this picture?
It is quite important for distro vendors because of the xlibs
separation. It would be cool to know how much time we have to split
XFree86-devel (or X11-devel in this case) dependencies into lib*-devel.
--
Regards,
Jakub Piotr C?apa
Date: Fri Jul 9 11:59:27 2004
In-Reply-To: <40EEC35D.4000601@niehs.nih.gov>
Isn't it great how our patent system is having the opposite effect?
Instead of encouraging the spread of ideas it is forcing people to keep
them secret.
--- Joe Krahn <krahn@niehs.nih.gov> wrote:
> Right. In other words, it all makes very little practical sense,
> but is very straight forward to lawyers. Things are more treacherous
> now with the huge number of software methods patents.
>
> In general, if there are enough hardware users to make the release
> of information profitable to them (the bottom line for any decision),
> then it probably is better to pay internal developers to do the work
> anyhow.
>
> BUT, I think the internal driver development by ATI and Nvidia could
> do much better with a public bug-tracking system. Maybe this would
> make it too easy for competitors to say "look at all of their bugs".
>
> Joe Krahn
>
> Jon Smirl wrote:
> > Talking to some of the Nvidia/ATI people I would say it is more out
> of
> > fear of being sued for patent infrigement that it is a desire to
> keep
> > anything secret. Providing the specs provides documantation for
> someone
> > to sue them with. It's unintentional infringement they are worried
> > about, not intentional.
> >
> > --- Sean Middleditch <elanthis@awesomeplay.com> wrote:
> >
> >>On Fri, 2004-07-09 at 10:12, David Eger wrote:
> >>
> >>>I'm curious:
> >>>
> >>>Why don't ATI/Nvidia/etc. ever seem to want to release programming
> >>
> >>specs
> >>
> >>>for their chips or source code for their drivers?
> >>
> >>This is a really old topic; the answer has been stated very many
> >>times
> >>before in the list archives and elsewhere...
> >>
> >>Long story short, they don't want competitors to know the
> interfaces
> >>to
> >>their hardware, or because they license hardware components from
> >>third
> >>parties, they are legally obligated not to release the hardware
> >>interface information.
> >>--
> >>Sean Middleditch <elanthis@awesomeplay.com>
> >>AwesomePlay Productions, Inc.
> >>
> >>
> >>_______________________________________________
> >>xorg mailing list
> >>xorg@freedesktop.org
> >>http://freedesktop.org/mailman/listinfo/xorg
> >>
> >
> >
> >
> > =====
> > Jon Smirl
> > jonsmirl@yahoo.com
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - 50x more storage than other providers!
> > http://promotions.yahoo.com/new_mail
> >
> > _______________________________________________
>
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
Date: Fri Jul 9 12:16:39 2004
In-Reply-To: Your message of "Fri, 09 Jul 2004 13:54:48 EDT."
<20040709175448.GB18379@kem.org>
Message-ID: <E1Bj0rJ-00067Y-1Y@evo.keithp.com>
Around 13 o'clock on Jul 9, Kevin E Martin wrote:
XFIXES:
In good shape. I'd like to get the RegionExpand code integrated
and tested as that seems necessary for some operations
DAMAGE/Composite:
See my separate message about background == None windows, other
than that, I've got several significant systems using Damage
and Composite with good results, so I think we're in pretty
good semantic shape here.
We still haven't got a 'clean' Composite implementation running
on XAA-based drivers (or in fact any drivers other than kdrive),
Deron Johnson has implemented a more generic wrapper layer but
hasn't sent that back to the community yet.
I've got a couple of works in progress which could be integrated into this
release:
1) TrueType wrappers for bitmap fonts. This converts .BDF fonts
into .TTF files, saving huge disk space, eliminating the
font compilation step and improving performance. Still
unfinished is code to add a custom TTF block to hold whatever
X specific values can't be crammed into standard TTF headers
and then a TTF to BDF converter so we can test the 'round trip'
ability of the system.
2) New Trapezoid specification for Render. Work on cairo has
uncovered fundemental problems in tesselation algorithms that
could take advantage of the funky Render trapezoids; it looks
like it will be better to respecify Render to include only
'normal' trapezoids and allow the weird representation for
backward compatibility while internally converting it to the
new format.
3) New trapezoid implementation for Render. The current
implementation is a disaster on many levels. We have
designed an alternate implementation but haven't managed to
implement it yet.
The last two are blessedly isolated from the bulk of the X server code but
a new trapezoid implementation should speed up cairo applications quite a
bit, especially when coupled with acceleration improvements for Render in
XAA and KAA.
I'm not sure I'll have time before mid-august for all of these projects,
so if others have an interest, I can help get them started.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040709/947f87fb/attach
ment.pgp
Date: Fri Jul 9 12:25:23 2004
Subject: [Xorg] Composite and Background == None windows
Message-ID: <E1Bj0zm-00067q-5T@evo.keithp.com>
I'm having trouble getting Background == None windows to work
right with Composite. The problem is that when these windows
are mapped, you get garbage contents for the backing pixmap.
Background == None windows are for two reasons:
1) To avoid flashing a background pixel which will
immediately be replaced by "real" contents.
2) To capture an image of the screen inside the window
I submit that case 1) is a more "legitimate" usage as 2) breaks in the
presense of different visuals in any case. So, it's important to
get case 1) right while still letting case 2) do something
reasonable.
For case 1) (used for menus and window manager frames), it seems
like the right solution is to avoid painting the window at all
until the application has managed to fill it entirely with the
correct content. That would require Damage to be modified to let the
application know when the window was completely painted, probably by
adding a boolean to the damage event to pass that information along.
However, when you create a Damage structure for a window, it is
initialized to the borderClip for that window; if the window is mapped
(and it often is, even for new windows because applications are pretty
quick to create/map menus) then the whole window ends up damaged, even
though it hasn't painted anything yet. I don't see how to fix that --
the new Damage would have no context to know whether the bits in the
window were painted by the application or not.
However, we can easily solve case 2) -- just copy the screen area to the
backing pixmap when the window is mapped. If the compositing manager is
doing anything weird with the windows, you may get strange looking results
though -- any shadows will be painted around the "window", even though
that "window" was filled with bits from the screen underneath it.
I guess the right solution is to implement the trivial fix for 2) and then
work on ICCCM extensions for applications to communicate with the
compositing manager about window painting state. Those extensions are
required to avoid screen artifacts in other cases, so I guess it's not so
bad that we need them for menus as well.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040709/ea413875/attach
ment.pgp
Date: Fri Jul 9 12:35:03 2004
Subject: [Xorg] Notes from release call
Here are a few notes I'm writing down from the release call, in case we
don't get minutes. I wasn't paying attention to who said what, so these
are just my impressions/conclusions from the call and are not complete
in any way.
First topic was .so modules:
- keithp explained the debrix work on making the server use .so
modules. We should be able to produce .so modules that retain
cross-platform compatibility for anything using ELF by using the libc
wrapper, as long as the modules avoid certain hazardous functions
(setjmp/longjmp)
- debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
on autotooling the x server but have found sticky issues with modules
involving references to global symbols. They've been fixed in that
tree, mostly, but this may prove to be a hazard for vendors moving to
.so modules
- We should make our modules as .so, which gives us more architecture
support and debugging ability, but retain the old loader if it proves
difficult to make the switch fully. We could also take vendors' .a
modules they produce and convert them to .so using ld probably.
- Has anyone tested .so modules cross-platform? Nobody on the call at
least. anholt was volunteered for testing.
Modularizing the build:
- keithp had volunteered, eich had volunteered to help, but progress has
stalled due to lack of time.
- keithp doesn't have time until at least 3 weeks from now
- Many, but by no means all libraries have been autotooled in the xlibs
project, so we have a basis to work from
- Modularizing of xorg can be done incrementally. First, rearrange
includes directory to make modular while retaining imake build, which
allows the libs to be done. Later the xserver autotooling can be
brought in, at which point the imake build can be left to rot.
Composite:
- anholt has attempted to do Composite support for XAA, which was never
completed, but the first thing to do would be to make a wrapper at the
miext layer that retained binary compatibility.
- If we move the new fields in PixmapRec to the end, we shouldn't have
any binary compat issues, because nobody should be statically allocating
PixmapRecs (since they wouldn't have the privates), or at least if they
do, the rest of the server shouldn't be seeing them.
- anholt concerned about doing Composite wrapper because of lack of
experience, eich suggested he could. (I'm attempting it anyway)
Release:
- Timing of next release: two months? end of year? next year?
- Proposed that we release in time for Fedora Core 3
- FC3 schedule would require a release by Sep 6?
- Proposed that we target having a release by Aug 25
- General agreement found.
- What should be in release? Composite/Damage/Fixes found general
agreement. What else? Call put out to xorg@
--
From alexdeucher at gmail.com Fri Jul 9 13:03:35 2004
Date: Fri Jul 9 13:04:01 2004
Message-ID: <a728f9f904070913033b01cf47@mail.gmail.com>
On Fri, 09 Jul 2004 11:29:03 -0700, Eric Anholt <eta@lclark.edu> wrote:
> On Fri, 2004-07-09 at 10:54, Kevin E Martin wrote:
> > On today's release wranglers call, the group discussed plans for having
> > the next X.Org Foundation release by August 25th. The primary new
> > features planned for this release are three new extensions: Damage,
> > XFixes and Composite.
> >
> > Some of the open questions are:
> >
> > - What is the state of each of these extensions, and what additional
> > work is needed to complete their integration into the CVS repository?
> > - What other functionality should be integrated before the release?
> > - Is the DRI support up-to-date or are there additional bug fixes that
> > need to be applied to the tree?
> > - What other patches/bug fixes are needed?
> > - Other items and/or open questions?
>
> AFAIK the damage/fixes bits are ready to go, but we'll want to test them
> with Composite and all the damage/fixes-using programs that composite
> allows. I've pushed "Doing Composite in xorg" up to the top of my TODO
> list so I should have something soon.
>
>
can we also confirm that the DDX changes from the DRI tree work? I'm
been meaning to test radeon mergedfb at least, but I've been super
busy lately and my laptop has become completely unreliable since
upgrading to fedora core 2. Plus the last time I tried to check out
the xorg cvs tree it failed somewhere in the build. It would also be
nice to get the rest of ati's code drop included (r400 support, new
crtc handling, etc.) however, I don't know when I or anyone else will
have time to integrate that.
Alex
> --
> Eric Anholt eta@lclark.edu
> http://people.freebsd.org/~anholt/ anholt@FreeBSD.org
>
>
>
>
> _______________________________________________
> xorg mailing list
>
Date: Fri Jul 9 13:23:29 2004
In-Reply-To: <40EEE97B.1030105@toya.net.pl>
<40EEE97B.1030105@toya.net.pl>
Hash: SHA1
On Friday 09 July 2004 14:52, Jakub Piotr C?apa wrote:
> And where is debrix in this picture?
> It is quite important for distro vendors because of the xlibs
> separation. It would be cool to know how much time we have to split
> XFree86-devel (or X11-devel in this case) dependencies into lib*-devel.
As long as daniels and I are the only ones beating on it there's probably no
way debrix could be ready by Aug 25. In addition to finishing the
autotooling, we'd still need several major modules imported, and a whole slew
of testers.
- - ajax
iD8DBQFA7v62W4otUKDs0NMRAlrPAJ48r2st97ai6G+zo54142i7UersMQCg6ICG
mdRc9UG/tJ5Y08V77TmjFOE=
=JLwz
Date: Fri Jul 9 13:31:02 2004
In-Reply-To: <a728f9f904070913033b01cf47@mail.gmail.com>
<a728f9f904070913033b01cf47@mail.gmail.com>
Message-ID: <20040709203058.GA21674@kem.org>
On Fri, Jul 09, 2004 at 04:03:35PM -0400, Alex Deucher wrote:
> It would also be
> nice to get the rest of ati's code drop included (r400 support, new
> crtc handling, etc.) however, I don't know when I or anyone else will
> have time to integrate that.
Hui is working on updating his code the last time I talked with him. He
said he would discuss it here when it was ready.
From sandmann at daimi.au.dk Fri Jul 9 14:14:46 2004
Date: Fri Jul 9 14:14:54 2004
Message-ID: <ye8zn687uih.fsf@ec02.daimi.au.dk>
Kevin E Martin <kem@freedesktop.org> writes:
>
I would like my MMX render patches in before that. They are a pretty
big improvement in the case where there isn't hardware accelerated
RENDER.
S?ren
Date: Fri Jul 9 14:34:36 2004
In-Reply-To: <ye8zn687uih.fsf@ec02.daimi.au.dk>
References: <20040709175448.GB18379@kem.org> <ye8zn687uih.fsf@ec02.daimi.au.dk>
On Fri, 2004-07-09 at 14:14, Soeren Sandmann wrote:
> Kevin E Martin <kem@freedesktop.org> writes:
>
> > Some of the open questions are:
> >
> > - What is the state of each of these extensions, and what additional
> > work is needed to complete their integration into the CVS repository?
> > - What other functionality should be integrated before the release?
> > - What other patches/bug fixes are needed?
>
> I would like my MMX render patches in before that. They are a pretty
> big improvement in the case where there isn't hardware accelerated
> RENDER.
We'll have quite a few render things to check out. There are some
non-mmx improvements in the kdrive fb code as well.
I'm really debating disabling all accelerated render in xaa until we
write a working hook. It doesn't pass in the destination format, so
currently the driver just has to guess what the dest format is, which is
wrong.
--
From michel at daenzer.net Fri Jul 9 15:21:50 2004
Date: Fri Jul 9 15:21:58 2004
On Fri, 2004-07-09 at 13:54 -0400, Kevin E Martin wrote:
>
The DRI code in the X.Org tree is broken in some respects on big endian
machines. I've fixed texturing in Mesa CVS, but there are probably still
issues with the new t_vertex code, which only affect software TCL
though, i.e. mostly Radeon 7000 and M6.
--
From andy at nospam.com Fri Jul 9 16:25:05 2004
From: andy at nospam.com (Andy Sy)
Date: Fri Jul 9 16:17:21 2004
Subject: [Xorg] X on OpenGL
Message-ID: <40EF2951.9020805@nospam.com>
In Keith's papers, he mentions having X use OpenGL 'for all graphics
operations'. Would something like the following layering work?
DRM ---> DRI (or KGI) ---> some sort of non-windowed/fullscreen
implementation of OpenGL ---> X
Is OpenGL really an appropriate API to build a windowing system on
top of? If it lacks certain calls to make such less kludgy, would
these (for sure, these would be 2d operations) be appropriately proposed
as OpenGL extensions or is everything elegantly expressible as a
special case of 3d?
The one big problem I see with the OpenGL API is that it does not give
you any direct pixel-level access to the frame buffer and wouldn't it
be extremely kludgy to build a windowing system without such?
-----------------------------------------
reply to: a n d y @ n e t f x p h . c o m
Date: Fri Jul 9 16:38:35 2004
In-Reply-To: <40EF2951.9020805@nospam.com>
References: <40EF2951.9020805@nospam.com>
Hash: SHA1
On Friday 09 July 2004 19:25, Andy Sy wrote:
> In Keith's papers, he mentions having X use OpenGL 'for all graphics
> operations'. Would something like the following layering work?
>
> DRM ---> DRI (or KGI) ---> some sort of non-windowed/fullscreen
> implementation of OpenGL ---> X
That is, in fact, the plan.
> Is OpenGL really an appropriate API to build a windowing system on
> top of? If it lacks certain calls to make such less kludgy, would
> these (for sure, these would be 2d operations) be appropriately proposed
> as OpenGL extensions or is everything elegantly expressible as a
> special case of 3d?
Anything it lacks can certainly be added, but I don't believe we've found any
cases like that yet. In particular, rectangles are just two adjacent
triangles with all Z coordinates equal.
> The one big problem I see with the OpenGL API is that it does not give
> you any direct pixel-level access to the frame buffer and wouldn't it
> be extremely kludgy to build a windowing system without such?
man glReadPixels.
- - ajax
iD8DBQFA7yxzW4otUKDs0NMRAi99AJ9CbJIUs7kfJTapd4JGzP8gfYYCkgCgw4Mj
vRSMnnbo2EWJHZXieDAiHqA=
=B60H
Date: Fri Jul 9 17:20:59 2004
<40EEE97B.1030105@toya.net.pl> <200407091623.19856.ajax@nwnk.net>
Message-ID: <40EF3667.5080006@toya.net.pl>
Adam Jackson wrote:
> On Friday 09 July 2004 14:52, Jakub Piotr C?apa wrote:
>
>>And where is debrix in this picture?
>>It is quite important for distro vendors because of the xlibs
>>separation. It would be cool to know how much time we have to split
>>XFree86-devel (or X11-devel in this case) dependencies into lib*-devel.
>
> As long as daniels and I are the only ones beating on it there's probably no
> way debrix could be ready by Aug 25. In addition to finishing the
> autotooling, we'd still need several major modules imported, and a whole slew
> of testers.
I understand. I'll try to do some betatesting and maybe small frame
development but need to rebuild some software with xlibs first. :)
I was asking about a longer period of time. Is first debrix release
expected this year or is monolithic tree planned to be the main tree for
next 2 years? :)
--
Regards,
Jakub Piotr C?apa
From d.jacobfeuerborn at conversis.de Fri Jul 9 17:31:42 2004
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Fri Jul 9 17:31:50 2004
Subject: [Xorg] Best config for Radeon 9x00?
Message-ID: <40EF38EE.4070806@conversis.de>
What is the best config to run the fdo xserver on a Radeon 9x00 (r300)
card? The only way I get things working so far is using Xvesa but that
is very slow. Xati only lists a maximum resolution of 640x480 and when I
start Xfbdev I only get a garbled screen (which I can get fixed by
running the regular Xorg server). What would be the best config to get
decent performance? I also got Waimea running and it would be neat to
use both of them as regular desktop even if they aren't for production
use right now. :)
Regards,
Dennis
From andy at nospam.com Fri Jul 9 17:49:49 2004
Date: Fri Jul 9 17:42:07 2004
References: <40EF2951.9020805@nospam.com> <200407091938.28777.ajax@nwnk.net>
Message-ID: <40EF3D2D.1080203@nospam.com>
Adam Jackson wrote:
>>The one big problem I see with the OpenGL API is that it does not give
>>you any direct pixel-level access to the frame buffer and wouldn't it
>>be extremely kludgy to build a windowing system without such?
>
>
> man glReadPixels.
>
> - - ajax
Right... glReadPixels, glCopyPixels and glDrawPixels... however
everyone says that implementations of these are dog-slow (abuse
of the hardware) and you're better off writing to a texture (which
is kludgy in many contexts)...
http://www.google.com/search?q=glReadPixels+slow&sourceid=mozilla-search&start=0
&start=0&ie=utf-8&oe=utf-8
http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=OpenGLBLit&btnG=Search
Why is it that OpenGL drivers seem to universally have this behaviour?
--
Date: Fri Jul 9 17:43:52 2004
Subject: [Xorg] [debrix] exported symbols
Message-ID: <40EF3BC6.6090407@toya.net.pl>
There seem to be two more missing symbols in the debrix binary and
without them driver-ati fails to load. Here is a patch:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-fbPictureInit.patch?rev=1
.2
--
Regards,
Jakub Piotr C?apa
From idr at us.ibm.com Fri Jul 9 17:48:12 2004
From: idr at us.ibm.com (Ian Romanick)
Date: Fri Jul 9 17:48:48 2004
Message-ID: <40EF3CCC.7050506@us.ibm.com>
Eric Anholt wrote:
Any bugs found in that area should be reported directly to me and the
dri-devel list. I'm going to try very hard to get the TLS support
finished this weekend. I've already done most of the work, so I should
have some sort done by Monday.
The approach I'm taking is diverging more and more from Jakub's original
patch (that's in Redhat and Fedora Core). The main issue is that a TLS
enabled libGL needs to be able to load & use a non-TLS enabled *_dri.so.
Thank you for reminding me about that. I'll try to take a look at that
one too.
From daniel at freedesktop.org Fri Jul 9 18:48:14 2004
Date: Fri Jul 9 18:48:17 2004
On Fri, Jul 09, 2004 at 04:23:18PM -0400, Adam Jackson wrote:
> On Friday 09 July 2004 14:52, Jakub Piotr C?apa wrote:
> > And where is debrix in this picture?
> > It is quite important for distro vendors because of the xlibs
> > separation. It would be cool to know how much time we have to split
> > XFree86-devel (or X11-devel in this case) dependencies into lib*-devel.
>
> As long as daniels and I are the only ones beating on it there's probably no
> way debrix could be ready by Aug 25. In addition to finishing the
> autotooling, we'd still need several major modules imported, and a whole slew
> of testers.
I could very ambitiously have the code there, but there's no way we'd
get testing enough to have it ready by Aug 25th.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/51ef3e3d/attach
ment.pgp
Date: Fri Jul 9 18:48:31 2004
In-Reply-To: <40EF3667.5080006@toya.net.pl>
<40EF3667.5080006@toya.net.pl>
Message-ID: <20040710014830.GF12023@fooishbar.org>
On Sat, Jul 10, 2004 at 02:20:55AM +0200, Jakub Piotr C?apa wrote:
> Adam Jackson wrote:
> >On Friday 09 July 2004 14:52, Jakub Piotr C?apa wrote:
> >>And where is debrix in this picture?
> >>It is quite important for distro vendors because of the xlibs
> >>separation. It would be cool to know how much time we have to split
> >>XFree86-devel (or X11-devel in this case) dependencies into lib*-devel.
> >
> >As long as daniels and I are the only ones beating on it there's probably
> >no way debrix could be ready by Aug 25. In addition to finishing the
> >autotooling, we'd still need several major modules imported, and a whole
> >slew of testers.
>
> I understand. I'll try to do some betatesting and maybe small frame
> development but need to rebuild some software with xlibs first. :)
>
> I was asking about a longer period of time. Is first debrix release
> expected this year or is monolithic tree planned to be the main tree for
> next 2 years? :)
This year.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/9a11644b/attach
ment.pgp
Date: Fri Jul 9 18:49:44 2004
In-Reply-To: <40EF3BC6.6090407@toya.net.pl>
References: <40EF3BC6.6090407@toya.net.pl>
Message-ID: <20040710014943.GG12023@fooishbar.org>
On Sat, Jul 10, 2004 at 02:43:50AM +0200, Jakub Piotr C??apa wrote:
> There seem to be two more missing symbols in the debrix binary and
> without them driver-ati fails to load. Here is a patch:
>
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-fbPictureInit.patch?rev
=1.2
Thanks. Does this get either of r128 or radeon loading for you?
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/ee9196f6/attach
ment.pgp
Date: Fri Jul 9 18:54:19 2004
In-Reply-To: <40EF3BC6.6090407@toya.net.pl>
Message-ID: <20040710015417.GH12023@fooishbar.org>
On Sat, Jul 10, 2004 at 02:43:50AM +0200, Jakub Piotr C??apa wrote:
> There seem to be two more missing symbols in the debrix binary and
> without them driver-ati fails to load. Here is a patch:
>
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-fbPictureInit.patch?rev
=1.2
Merged in my tla repository as
daniel@fooishbar.org--2004/debrix--devel--0.1--patch-2.
To use it:
% tla register-archive daniel@fooishbar.org---2004
http://fooishbar.org/daniel/arch/
% tla get daniel@fooishbar.org--2004/debrix--devel--0.1 debrix
% tla get daniel@fooishbar.org--2004/debrix-driver-ati--devel--0.1
debrix-driver-ati
[...]
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/a8076dd6/attach
ment.pgp
Date: Fri Jul 9 19:00:12 2004
References: <1089401669.891.93.camel@leguin>
Message-ID: <20040710020010.GI12023@fooishbar.org>
On Fri, Jul 09, 2004 at 12:34:29PM -0700, Eric Anholt wrote:
> - keithp explained the debrix work on making the server use .so
> modules. We should be able to produce .so modules that retain
> cross-platform compatibility for anything using ELF by using the libc
> wrapper, as long as the modules avoid certain hazardous functions
> (setjmp/longjmp)
Right. As long as you can assume the same processor platform, then all
you have to do is avoid platform-specific stuff: make sure your module
works with a baseline libc, and the X stuff.
> - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> on autotooling the x server but have found sticky issues with modules
> involving references to global symbols. They've been fixed in that
> tree, mostly, but this may prove to be a hazard for vendors moving to
> .so modules
Global symbols are OK, but they *must* be resolved at load time; they
cannot be lazily resolved. This means that the ATI driver, where ati had
global symbol deps on atimisc/r128/radeon, while the reverse was also
true, could not be loaded. Ever.
Right now, our compromise is that Load "ati" works, but
atimisc/r128/radeon doesn't. The current thinking (well, for me anyway),
is to make a fake libatimisc/libr128/libradeon which just depends on
libati, and then rename the real ones to libati_atimisc, or whatever.
> - We should make our modules as .so, which gives us more architecture
> support and debugging ability, but retain the old loader if it proves
> difficult to make the switch fully. We could also take vendors' .a
> modules they produce and convert them to .so using ld probably.
objcopy is good. You want objcopy. If someone adds XFree86-ELF support
to this, we could use objcopy to do a conversion to arbitrary formats.
> Modularizing the build:
> - keithp had volunteered, eich had volunteered to help, but progress has
> stalled due to lack of time.
> - keithp doesn't have time until at least 3 weeks from now
> - Many, but by no means all libraries have been autotooled in the xlibs
> project, so we have a basis to work from
> - Modularizing of xorg can be done incrementally. First, rearrange
> includes directory to make modular while retaining imake build, which
> allows the libs to be done. Later the xserver autotooling can be
> brought in, at which point the imake build can be left to rot.
I have been doing a lot of modularisation work, but all in modular trees
at this stage.
> - If we move the new fields in PixmapRec to the end, we shouldn't have
> any binary compat issues, because nobody should be statically allocating
> PixmapRecs (since they wouldn't have the privates), or at least if they
> do, the rest of the server shouldn't be seeing them.
You can keep binary-compat if you add new members to the end of
structures, yes.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/3a4c96b6/attach
ment.pgp
Date: Fri Jul 9 19:15:36 2004
In-Reply-To: <40EF2951.9020805@nospam.com>
--- Andy Sy <andy@nospam.com> wrote:
> In Keith's papers, he mentions having X use OpenGL 'for all graphics
> operations'. Would something like the following layering work?
>
> DRM ---> DRI (or KGI) ---> some sort of non-windowed/fullscreen
> implementation of OpenGL ---> X
The full screen OpenGL code is this project:
http://mesa3d.sourceforge.net/fbdev-dri.html
It is a derivative of X's DRI.
The right model is:
DRM -> DRI (mesa-solo version) --> X
We are 98% of the way to mesa-solo and X DRI being the same shared
object.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Date: Fri Jul 9 19:58:24 2004
In-Reply-To: <20040710020010.GI12023@fooishbar.org>
<20040710020010.GI12023@fooishbar.org>
Hash: SHA1
On Friday 09 July 2004 22:00, Daniel Stone wrote:
> On Fri, Jul 09, 2004 at 12:34:29PM -0700, Eric Anholt wrote:
> > - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> > on autotooling the x server but have found sticky issues with modules
> > involving references to global symbols. They've been fixed in that
> > tree, mostly, but this may prove to be a hazard for vendors moving to
> > .so modules
>
> Global symbols are OK, but they *must* be resolved at load time; they
> cannot be lazily resolved. This means that the ATI driver, where ati had
> global symbol deps on atimisc/r128/radeon, while the reverse was also
> true, could not be loaded. Ever.
>
> Right now, our compromise is that Load "ati" works, but
> atimisc/r128/radeon doesn't. The current thinking (well, for me anyway),
> is to make a fake libatimisc/libr128/libradeon which just depends on
> libati, and then rename the real ones to libati_atimisc, or whatever.
Not to be contrary, but I'd thought I'd resolved that (ie, that you could load
r128 on its own without ati first). If not, perhaps everything except the
chipset detection could be factored out into, say, aticore, which would then
be loaded by atimisc/r128/radeon. 'ati' would then be shorthand for "I'm too
lazy to figure out which chip I have, please load the right one for me".
Alternatively, if there exists a loader call that can query if a module is
already loaded, we can stick that at the beginning of the atimisc/r128/radeon
init routines.
Any of the above works for me, but I think I like the aticore approach best if
it's feasible.
- - ajax
iD8DBQFA71tMW4otUKDs0NMRAjbGAKC4PtTKioeINBcBy39TtPMQ/ihZ5QCgkq5p
5UuKIY6c9vI+rXKx/IZeduc=
=+/89
Date: Fri Jul 9 20:02:13 2004
<20040710020010.GI12023@fooishbar.org>
<200407092258.20922.ajax@nwnk.net>
On Fri, Jul 09, 2004 at 10:58:19PM -0400, Adam Jackson wrote:
> On Friday 09 July 2004 22:00, Daniel Stone wrote:
> > On Fri, Jul 09, 2004 at 12:34:29PM -0700, Eric Anholt wrote:
> > > - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> > > on autotooling the x server but have found sticky issues with modules
> > > involving references to global symbols. They've been fixed in that
> > > tree, mostly, but this may prove to be a hazard for vendors moving to
> > > .so modules
> >
> > Global symbols are OK, but they *must* be resolved at load time; they
> > cannot be lazily resolved. This means that the ATI driver, where ati had
> > global symbol deps on atimisc/r128/radeon, while the reverse was also
> > true, could not be loaded. Ever.
> >
> > Right now, our compromise is that Load "ati" works, but
> > atimisc/r128/radeon doesn't. The current thinking (well, for me anyway),
> > is to make a fake libatimisc/libr128/libradeon which just depends on
> > libati, and then rename the real ones to libati_atimisc, or whatever.
>
> Not to be contrary, but I'd thought I'd resolved that (ie, that you could load

> r128 on its own without ati first). If not, perhaps everything except the
> chipset detection could be factored out into, say, aticore, which would then
> be loaded by atimisc/r128/radeon. 'ati' would then be shorthand for "I'm too
> lazy to figure out which chip I have, please load the right one for me".
> Alternatively, if there exists a loader call that can query if a module is
> already loaded, we can stick that at the beginning of the atimisc/r128/radeon
> init routines.
>
> Any of the above works for me, but I think I like the aticore approach best if

> it's feasible.
Oh, OK. I was just going on that we hadn't fixed that yet. My bad.
Nothing to see here. Move along, please. :)
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/49a9758e/attach
ment.pgp
Date: Fri Jul 9 20:20:21 2004
In-Reply-To: <40EF3D2D.1080203@nospam.com>
<40EF3D2D.1080203@nospam.com>
Hash: SHA1
On Friday 09 July 2004 20:49, Andy Sy wrote:
> >>The one big problem I see with the OpenGL API is that it does not give
> >>you any direct pixel-level access to the frame buffer and wouldn't it
> >>be extremely kludgy to build a windowing system without such?
> >
> > man glReadPixels.
>
> Right... glReadPixels, glCopyPixels and glDrawPixels... however
> everyone says that implementations of these are dog-slow (abuse
> of the hardware) and you're better off writing to a texture (which
> is kludgy in many contexts)...
>
> <snip>
>
> Why is it that OpenGL drivers seem to universally have this behaviour?
I suspect that, in order to get consistent results, the gl*Pixels calls are
implicitly preceeded by a glFinish call, which would impose a synchronization
penalty. So the Pixel function itself could be fast in terms of bandwidth
but not in terms of latency, and calling it in a loop from 1 to 2000 would
hurt. This might not be true for glDrawPixels since the results would be
drawn in sequence with other GL commands, but Read and Copy might need to
wait for drawing to finish before reading. (If this is a real problem it
might be possible to design an async Read API that allows the app to request
the pixels early and only block on the results when it really needs them.)
Several of the DRI drivers have DMA-accelerated gl*Pixels functions, with
something on the order of 1GB/sec bandwidth not being uncommon. Perhaps
that's not fast enough. At any rate the DRI drivers know where the
framebuffer is, and could be extended to enable direct access to the
application.
DRI is quite flexible, things like DGA and XV could be implemented in terms of
the DRI framework. DRI just happens to get used to implement fast GL
drivers. It might be more accurate to say that the goal is to make the X
server a DRI client rather than an OpenGL app.
- - ajax
iD8DBQFA72BvW4otUKDs0NMRAh0gAKCFvCNpJlfml8EnOHq0GAmCJDVGXgCfQZZl
qBWo5loPnoXTH+BMawLtbxQ=
=H6/I
Date: Fri Jul 9 21:58:48 2004
In-Reply-To: Your message of "Sat, 10 Jul 2004 07:25:05 +0800."
<40EF2951.9020805@nospam.com>
Message-ID: <E1Bj9wd-0006IW-J9@evo.keithp.com>
Around 7 o'clock on Jul 10, Andy Sy wrote:
> The one big problem I see with the OpenGL API is that it does not give
> you any direct pixel-level access to the frame buffer and wouldn't it
> be extremely kludgy to build a windowing system without such?
X has been implemented on many systems without direct pixel access; as
long as the system provides the basic pixel manipulations necessary for
the core (and Render) protocols, we're all set. And, as ajax says, we can
always use glReadPixels
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040709/aa38a07c/attach
ment.pgp
Date: Fri Jul 9 22:08:54 2004
In-Reply-To: Your message of "Fri, 09 Jul 2004 23:20:15 EDT."
<200407092320.16722.ajax@nwnk.net>
Message-ID: <E1BjA6N-0006KU-Ab@evo.keithp.com>
Around 23 o'clock on Jul 9, Adam Jackson wrote:
> It might be more accurate to say that the goal is to make the X
> server a DRI client rather than an OpenGL app.
While that would be possible, that's not my goal -- if GL is available, I'd
rather just use that for the driver API. We may want a few extensions, but
the X server should be able to run on plain unextended GL. David Reveman
and Peter Nilsson show us with Glitz just how feasible this is; glitz
provides essentially all of the Render semantics on GLX and AGL (with WGL
support coming soon).
Where GL isn't available, we'll do something else, probably using some of
the research that Eric Anholt has done on the R128/Radeon cards (although
those happen to have nice GL acceleration too).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040709/e1f7bbe4/attach
ment.pgp
Date: Fri Jul 9 22:28:29 2004
In-Reply-To: <E1BjA6N-0006KU-Ab@evo.keithp.com>
References: <E1BjA6N-0006KU-Ab@evo.keithp.com>
Hash: SHA1
On Saturday 10 July 2004 01:08, Keith Packard wrote:
> Around 23 o'clock on Jul 9, Adam Jackson wrote:
> > It might be more accurate to say that the goal is to make the X
> > server a DRI client rather than an OpenGL app.
>
> While that would be possible, that's not my goal -- if GL is available, I'd
> rather just use that for the driver API. We may want a few extensions, but
> the X server should be able to run on plain unextended GL. David Reveman
> and Peter Nilsson show us with Glitz just how feasible this is; glitz
> provides essentially all of the Render semantics on GLX and AGL (with WGL
> support coming soon).
Yes; I hesitated even saying it, because someone might misread it as giving
nVidia users the shaft, what with their non-DRI GL drivers. Hence 'might'.
> Where GL isn't available, we'll do something else, probably using some of
> the research that Eric Anholt has done on the R128/Radeon cards (although
> those happen to have nice GL acceleration too).
One thing I've been wanting for a while is a DRI driver that is purely
software fallback. I hacked out a skeleton for it, but it needs a lot more
work. There's several advantages to getting it working:
- - Classic X servers can load that instead of GLcore, paving the way for
accelerated indirect rendering
- - Clients draw right on the window instead of hitting the X server with
millions of XPutPixels
- - Opportunity for DGA-style acceleration for non-3D cards
- - Base class for people to derive new hardware drivers from
- - Could act as dumb framebuffer driver for solo (does drivers/dri/fb even work

anymore?)
etc. I hope to get it working after fixing things for the libdl loader.
- - ajax
iD8DBQFA735nW4otUKDs0NMRAuPeAJ0T2dcURkfSca6/hrTkUShn0wsJtQCdFvAI
fSn5Lr5KedmFzhBSAxK019c=
=Wwts
Date: Fri Jul 9 22:39:17 2004
--- Adam Jackson <ajax@nwnk.net> wrote:
> - - Could act as dumb framebuffer driver for solo (does
> drivers/dri/fb even work anymore?)
fb got broken in the big fbconfig merge with dri. It just needs some
minor work to fix it up with the framebuffer width, height, pitch when
it gets initially created. I disabled it from the compile until
someone fixes it - it's about an hour of work. Turn it on at the bottom
of config/linux-solo and fix the compile errors, they show you exactly
what needs to be fixed.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From c99drn at cs.umu.se Sat Jul 10 00:16:32 2004
From: c99drn at cs.umu.se (David Reveman)
Date: Sat Jul 10 00:16:52 2004
<40EF3D2D.1080203@nospam.com> <200407092320.16722.ajax@nwnk.net>
Message-ID: <1089443792.23820.17.camel@ion.david>
On Fri, 2004-07-09 at 23:20 -0400, Adam Jackson wrote:
> Hash: SHA1
>
> On Friday 09 July 2004 20:49, Andy Sy wrote:
> > Adam Jackson wrote:
> > >>The one big problem I see with the OpenGL API is that it does not give
> > >>you any direct pixel-level access to the frame buffer and wouldn't it
> > >>be extremely kludgy to build a windowing system without such?
> > >
> > > man glReadPixels.
> >
> > Right... glReadPixels, glCopyPixels and glDrawPixels... however
> > everyone says that implementations of these are dog-slow (abuse
> > of the hardware) and you're better off writing to a texture (which
> > is kludgy in many contexts)...
> >
> > <snip>
> >
> > Why is it that OpenGL drivers seem to universally have this behaviour?
>
> I suspect that, in order to get consistent results, the gl*Pixels calls are
> implicitly preceeded by a glFinish call, which would impose a synchronization
> penalty. So the Pixel function itself could be fast in terms of bandwidth
> but not in terms of latency, and calling it in a loop from 1 to 2000 would
> hurt. This might not be true for glDrawPixels since the results would be
> drawn in sequence with other GL commands, but Read and Copy might need to
> wait for drawing to finish before reading. (If this is a real problem it
> might be possible to design an async Read API that allows the app to request
> the pixels early and only block on the results when it really needs them.)
>
> Several of the DRI drivers have DMA-accelerated gl*Pixels functions, with
> something on the order of 1GB/sec bandwidth not being uncommon. Perhaps
> that's not fast enough. At any rate the DRI drivers know where the
> framebuffer is, and could be extended to enable direct access to the
> application.
>
> DRI is quite flexible, things like DGA and XV could be implemented in terms of

> the DRI framework. DRI just happens to get used to implement fast GL
> drivers. It might be more accurate to say that the goal is to make the X
I've added support for async DMA-accelerated pixel transfers to glitz,
right now it will only make a difference for hardware/drivers that
support the GL_EXT_pixel_buffer_object extension [1]. However, it
provides a very nice interface for efficient pixel transfers and the
GL_EXT_pixel_buffer_object extension also allow us to specify the
purpose of a memory buffer and allocates appropriate memory for us. e.g.
write-combined uncached AGP memory for draw and cached memory for read.
So far, I haven't been able to do much testing but the latest nvidia
drivers support this extension and a simple glitz video-out module for
mplayer showed a 100% performance increase in the video-out module on a
4 year old motherboard with a geforce2mx card. Performance gain is
probably even better on newer systems, I think nvidia is now actually
using the 3D engine to do Xv PutImage requests for Xv adapters on
geforce4 and geforceFX cards in their latest driver.
None of this code has been committed glitz CVS yet, but I'll try to get
it done sometime during this weekend.
It would be interesting to see how hard it would be to add support for
the GL_EXT_pixel_buffer_object extension to some of DRI drivers, as you
said "DRI is quite flexible".
I think mesa-software support GL_EXT_pixel_buffer_object.
[1]
http://oss.sgi.com/projects/ogl-sample/registry/EXT/pixel_buffer_object.txt
-David
From michel at daenzer.net Sat Jul 10 02:51:47 2004
Date: Sat Jul 10 02:51:55 2004
On Fri, 2004-07-09 at 23:20 -0400, Adam Jackson wrote:
>
> On Friday 09 July 2004 20:49, Andy Sy wrote:
> >
> >
> > <snip>
> >
Maybe because they aren't crucial to the performance of the average
first person shooter? ;)
> DRI is quite flexible, things like DGA and XV could be implemented in terms of

> the DRI framework. DRI just happens to get used to implement fast GL
> drivers. It might be more accurate to say that the goal is to make the X
That would be a bad idea IMHO. We have this widely used and extensible
API called OpenGL, why move ourselves into a corner by depending on DRI
specific APIs?
--
From andy at nospam.com Sat Jul 10 03:26:08 2004
Date: Sat Jul 10 03:19:17 2004
Subject: [Xorg] X and Render protocol level reference (was Re: X on OpenGL)
In-Reply-To: <E1Bj9wd-0006IW-J9@evo.keithp.com>
References: <E1Bj9wd-0006IW-J9@evo.keithp.com>
Message-ID: <40EFC440.5000601@nospam.com>
> X has been implemented on many systems without direct pixel access; as
> long as the system provides the basic pixel manipulations necessary for
> the core (and Render) protocols, we're all set. And, as ajax says, we can
> always use glReadPixels
Speaking of protocols, is there a free electronic copy of the reference for
these protocols? For a standard as open and free as X, I can't believe the
only source for it seems to be the (out-of-print?) volume 0 Protocol
Reference Manual from O'Reilly.
Are there also publicly available documentation for protocol level
Render?
--
Date: Sat Jul 10 03:42:27 2004
In-Reply-To: <20040710014943.GG12023@fooishbar.org>
<20040710014943.GG12023@fooishbar.org>
Message-ID: <40EFC80D.1010201@toya.net.pl>
Daniel Stone wrote:
> On Sat, Jul 10, 2004 at 02:43:50AM +0200, Jakub Piotr C??apa wrote:
>
>>There seem to be two more missing symbols in the debrix binary and
>>without them driver-ati fails to load. Here is a patch:
>>
>>http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-fbPictureInit.patch?rev
=1.2
>
> Thanks. Does this get either of r128 or radeon loading for you?
Checking... Yes. Both radeon anr r128 load without errors.
What's still wrong:
#v+
(EE) Couldn't load builtin module "xf4bpp"
(EE) Failed to load module "xf4bpp" (invalid argument(s) to LoadModule(), 1)
#v-
Driver "radeon" still fails (doesn't load ati). Adding Module "ati"
helps but it's no better than just using Driver "ati".
Also I have some minor visial glitches with xfwm4 in the corners of the
windows. Would you like a screenshot? ;)
--
Regards,
Jakub Piotr C?apa
From ajax at nwnk.net Sat Jul 10 04:44:26 2004
Date: Sat Jul 10 04:44:36 2004
In-Reply-To: <40EFC80D.1010201@toya.net.pl>
<20040710014943.GG12023@fooishbar.org>
<40EFC80D.1010201@toya.net.pl>
Hash: SHA1
On Saturday 10 July 2004 06:42, Jakub Piotr C?apa wrote:
> <snip>
> Also I have some minor visial glitches with xfwm4 in the corners of the
> windows. Would you like a screenshot? ;)
Only if the workaround in http://freedesktop.org/bugzilla/show_bug.cgi?id=756
doesn't fix it...
- - ajax
iD8DBQFA79aeW4otUKDs0NMRAqD9AKDbU22dBEvPqax//FOemQf1YUm8WwCgtuAU
z9Pb/rHQxLAbIotkN8mA52I=
=9Pez
Date: Sat Jul 10 05:34:45 2004
<20040710014943.GG12023@fooishbar.org>
<40EFC80D.1010201@toya.net.pl> <200407100744.32179.ajax@nwnk.net>
Message-ID: <40EFE261.6040006@toya.net.pl>
Adam Jackson wrote:
> Hash: SHA1
>
> On Saturday 10 July 2004 06:42, Jakub Piotr C?apa wrote:
>
>><snip>
>>Also I have some minor visial glitches with xfwm4 in the corners of the
^^^^^
>>windows. Would you like a screenshot? ;)
>
> Only if the workaround in http://freedesktop.org/bugzilla/show_bug.cgi?id=756
> doesn't fix it...
Your screenshot doesn't look like a showcase of a minor glitch to me. :D
No. This option doesn't change anything (look at the corners of the
windows):
https://mimiru.one.pl/~jpc/images/debrix-gcmd.png
https://mimiru.one.pl/~jpc/images/xorg-gcmd.png
I still don't have gnome-terminal compiled because it needs libGLU. (it
should be taken from Mesa on an xlibs based system?) Last time I've
tried it was severly broken but so was my X11-libs/xlibs mixture.
--
Regards,
Jakub Piotr C?apa
Date: Sat Jul 10 05:42:37 2004
In-Reply-To: <40EFE261.6040006@toya.net.pl>
References: <40EF3BC6.6090407@toya.net.pl> <200407100744.32179.ajax@nwnk.net>
<40EFE261.6040006@toya.net.pl>
Hash: SHA1
On Saturday 10 July 2004 08:34, Jakub Piotr C?apa wrote:
> > On Saturday 10 July 2004 06:42, Jakub Piotr C?apa wrote:
> >>Also I have some minor visial glitches with xfwm4 in the corners of the
> ^^^^^
> >>windows. Would you like a screenshot? ;)
> >
> > Only if the workaround in
> > http://freedesktop.org/bugzilla/show_bug.cgi?id=756 doesn't fix it...
>
> Your screenshot doesn't look like a showcase of a minor glitch to me. :D
Didn't you know the whole point of bugzilla was to take astonishingly worrying
screenshots? ;)
> No. This option doesn't change anything (look at the corners of the
> windows):
> https://mimiru.one.pl/~jpc/images/debrix-gcmd.png
> https://mimiru.one.pl/~jpc/images/xorg-gcmd.png
Dang. I think we got a partially munged XAA when we branched. Any chance one
of the other XAA options is the culprit?
> I still don't have gnome-terminal compiled because it needs libGLU.
Jaw, meet floor.
- - ajax
iD8DBQFA7+Q4W4otUKDs0NMRAt49AKCPCzKLT+WhScAHPAQt3fXAeRUwNQCg3WsE
5EdMQ7J9rNl7mnhAWDWe30M=
=go/3
Date: Sat Jul 10 09:44:45 2004
<40EFE261.6040006@toya.net.pl> <200407100842.33294.ajax@nwnk.net>
Message-ID: <40F01CF9.8080904@toya.net.pl>
Adam Jackson wrote:
>>Adam Jackson wrote:
>>>On Saturday 10 July 2004 06:42, Jakub Piotr C?apa wrote:
>>>>Also I have some minor visial glitches with xfwm4 in the corners of the
>> ^^^^^
>>>>windows. Would you like a screenshot? ;)
>>>
>>>Only if the workaround in
>>>http://freedesktop.org/bugzilla/show_bug.cgi?id=756 doesn't fix it...
>>
>>Your screenshot doesn't look like a showcase of a minor glitch to me. :D
>
> Didn't you know the whole point of bugzilla was to take astonishingly worrying

> screenshots? ;)
;]
>>No. This option doesn't change anything (look at the corners of the
>>windows):
>>https://mimiru.one.pl/~jpc/images/debrix-gcmd.png
>>https://mimiru.one.pl/~jpc/images/xorg-gcmd.png
>
> Dang. I think we got a partially munged XAA when we branched. Any chance one

> of the other XAA options is the culprit?
And what are the other options? I haven't seen a list anywhere...
NoAccel, apart from making things really sluggish, doesn't help.
>>I still don't have gnome-terminal compiled because it needs libGLU.
>
> Jaw, meet floor.
I dont really know why, but it seems to need it. :) gnome-terminal
showed itself on a debrix server but it loaded libGLU.so from X11-libs
(the monolithic tree) and severely corrupted the screen. Now I'm playing
in a chroot and I don't have anything but xlibs installed.
--
Regards,
Jakub Piotr C?apa
Date: Sat Jul 10 09:46:35 2004
In-Reply-To: <40EFC80D.1010201@toya.net.pl>
References: <40EF3BC6.6090407@toya.net.pl> <20040710014943.GG12023@fooishba
r.org>
<40EFC80D.1010201@toya.net.pl>
Message-ID: <40F01D67.1070304@toya.net.pl>
Jakub Piotr C?apa wrote:
>
>> On Sat, Jul 10, 2004 at 02:43:50AM +0200, Jakub Piotr C??apa wrote:
>>
>>> There seem to be two more missing symbols in the debrix binary and
>>> without them driver-ati fails to load. Here is a patch:
>>>
>>> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-fbPictureInit.patch?r
ev=1.2
>>>
>>
>>
>> Thanks. Does this get either of r128 or radeon loading for you?
>
> What's still wrong:
> #v+
> (EE) Couldn't load builtin module "xf4bpp"
> (EE) Failed to load module "xf4bpp" (invalid argument(s) to
> LoadModule(), 1)
> #v-
Thanks to Jakub Stachowski I have a fix for that. It's quite strange why
it is required but it seems that loading a submodule fails when the
module path is not initialized.
The patch:
#v+
--- orig/hw/xorg/common/xf86Init.c
+++ mod/hw/xorg/common/xf86Init.c
@@ -337,14 +337,14 @@
/* Initialise the loader */
LoaderInit();
+ /* Tell the loader the default module search path */
+ LoaderSetPath(xf86ModulePath);
+
#ifdef DEBRIX
/* Tell the loader about our built-ins. */
debrixInit();
#endif
- /* Tell the loader the default module search path */
- LoaderSetPath(xf86ModulePath);
-
#ifdef TESTING
{
char **list, **l;
#v-
I've tried Arch but it's braindamaged. The command lines make my fingers
hurt and the whole concept is nothing I can understand without several
hours of digging throught it. Any *good* tutorials?
--
Regards,
Jakub Piotr C?apa
From keithp at keithp.com Sat Jul 10 10:10:49 2004
Date: Sat Jul 10 10:11:19 2004
Subject: [Xorg] X and Render protocol level reference (was Re: X on
OpenGL)
<40EFC440.5000601@nospam.com>
Message-ID: <E1BjLNC-0006cp-Ul@evo.keithp.com>
> Speaking of protocols, is there a free electronic copy of the reference for
> these protocols?
You can download a PDF version of the OpenGL spec from SGI (iirc)
The X protocol specification is part of the X distribution; you can find a
postscript version in CVS:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/doc/hardcopy/XProtocol/proto.
PS.gz
The same goes for Render, except that it's a pure ASCII spec (ala IETF
RFCs):
http://freedesktop.org/cgi-bin/viewcvs.cgi/xlibs/Render/protocol
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/cefb3aae/attach
ment.pgp
From otaylor at redhat.com Sat Jul 10 10:30:37 2004
From: otaylor at redhat.com (Owen Taylor)
Date: Sat Jul 10 10:31:23 2004
In-Reply-To: <40F01CF9.8080904@toya.net.pl>
<200407100744.32179.ajax@nwnk.net> <40EFE261.6040006@toya.net.pl>
<200407100842.33294.ajax@nwnk.net> <40F01CF9.8080904@toya.net.pl>
> >>I still don't have gnome-terminal compiled because it needs libGLU.
> >
> > Jaw, meet floor.
>
> I dont really know why, but it seems to need it. :) gnome-terminal
> showed itself on a debrix server but it loaded libGLU.so from X11-libs
> (the monolithic tree) and severely corrupted the screen. Now I'm playing
> in a chroot and I don't have anything but xlibs installed.
You can build GL rendering into libvte, but it's off by default unless
you specify --with-glX on the configure line.
One of the many cases where you should trust the maintainer's choice
as to the default configure options....
Regards,
Owen
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/3c5d1045/attach
ment.pgp
Date: Sat Jul 10 11:19:46 2004
References: <40EF3BC6.6090407@toya.net.pl> <200407100744.32179.ajax@nwnk.n
et>
<40EFE261.6040006@toya.net.pl> <200407100842.33294.ajax@nwnk.net>
<40F01CF9.8080904@toya.net.pl>
Message-ID: <40F0333F.3070506@toya.net.pl>
Owen Taylor wrote:
>>>>I still don't have gnome-terminal compiled because it needs libGLU.
>>>
>>>Jaw, meet floor.
>>
>>I dont really know why, but it seems to need it. :) gnome-terminal
>>showed itself on a debrix server but it loaded libGLU.so from X11-libs
>>(the monolithic tree) and severely corrupted the screen. Now I'm playing
>>in a chroot and I don't have anything but xlibs installed.
>
> You can build GL rendering into libvte, but it's off by default unless
> you specify --with-glX on the configure line.
Maybe you know what's the real difference between this two?
> One of the many cases where you should trust the maintainer's choice
> as to the default configure options....
I'm used to trust my distro developer's (I happen to be one of them)
choice of configure options. Of cource everybody sometimes make
mistakes, don't they?
--
Regards,
Jakub Piotr C?apa
Date: Sat Jul 10 12:38:20 2004
Subject: [Xorg] Re: [Mesa3d-dev] make linux-solo build problem
In-Reply-To: <4d3893dedf2a9a5fab38a7be9433500b@debian>
Here's glitz-miniglx.pc.in
--- Rogelio Serrano <rogelio@smsglobal.net> wrote:
> On 2004-07-09 09:23:02 +0800 Jon Smirl <jonsmirl@yahoo.com>
> wrote:
>
> > --- "Rogelio M.Serrano Jr." <rogelio@smsglobal.net> wrote:
> >> Thats great. I cant wait to start porting glitz.
> >
> > I already hacked things to bring up glitz. The attach patch
> > makes a
> > miniglx target for glitz. You also need to stub out some X
> > routines in
> > miniglx to make glitz happy. You also have to switch from X
> > input
> > routines to the kernel ones.
> >
> > glitz on miniglx isn't near being finished. I got halfway
> > through
> > making things work when Ian made the fbconfig changes and I
> > stopped to
> > fix mesa-solo for them. But I was able to run most of the
> > glitz test
> > programs.
> > There are no significant problems with run glitz on a r200.
> > The most
> > important thing needed is for the driver to support
> > render-to-texture
> > and get rid of the need for root priv.
> >
> > =====
> > Jon Smirl
> >
>
> I just tried the patch. When i run autogen.sh
> glitz-miniglx.pc.in is missing.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
-------------- next part --------------
Name: glitz-miniglx.pc.in
Type: application/octet-stream
Size: 289 bytes
Desc: glitz-miniglx.pc.in
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/b2d5db0c/glitz-
miniglx.pc.obj
From solerman at wonder.com.br Sat Jul 10 12:49:38 2004
From: solerman at wonder.com.br (Solerman Kaplon)
Date: Sat Jul 10 12:48:50 2004
Subject: [Fwd: Re: [Xorg] X on OpenGL]
Message-ID: <40F04852.1030208@wonder.com.br>
-------- Original Message --------> forgott the replly all too
David Reveman wrote:
[snip]
>Performance gain is
>probably even better on newer systems, I think nvidia is now actually
>using the 3D engine to do Xv PutImage requests for Xv adapters on
>geforce4 and geforceFX cards in their latest driver.
>
>
Correct, from the release highlights (
http://www.nvidia.com/object/linux_display_ia32_1.0-6106.html ):
- Added a new Xv adaptor on GeForce4 and GeForce FX which uses the 3D
engine to do Xv PutImage requests.
From qbast at go2.pl Sat Jul 10 13:18:20 2004
From: qbast at go2.pl (Jakub Stachowski)
Date: Sat Jul 10 13:17:38 2004
Subject: [Xorg] [debrix] trident driver
Message-ID: <200407102218.20426.qbast@go2.pl>
Hello,
I finished autotooling trident driver for debrix. First patch is against
debrix-driver-trident from xserver cvs. It is based on autotooled ati driver.
Second patch is for debrix/hw/xorg/loader/xf86sym.c from Daniel Stone's arch
repository with patch from Jakub Piotr C?apa (posted earlier). It adds some
symbols referenced by the driver.
Tested on Toshiba laptop with CyberBlade/XP - everything works without
problems.
-------------- next part --------------
Name: trident.patch
Type: text/x-diff
Size: 3098 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/9f51972c/triden
t.bin
-------------- next part --------------
Name: xf86sym.patch
Type: text/x-diff
Size: 635 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/9f51972c/xf86sy
m.bin
From vektor at dumbterm.net Sat Jul 10 15:10:29 2004
Date: Sat Jul 10 15:10:36 2004
Subject: [Fwd: Re: [Xorg] X on OpenGL]
In-Reply-To: <40F04852.1030208@wonder.com.br>
References: <40F04852.1030208@wonder.com.br>
Message-ID: <20040710221029.GA5930@dumbterm.net>
Solerman Kaplon (solerman@wonder.com.br):
> David Reveman wrote:
> >Performance gain is probably even better on newer systems, I think
> >nvidia is now actually using the 3D engine to do Xv PutImage requests
> >for Xv adapters on geforce4 and geforceFX cards in their latest
> >driver.
>
> Correct, from the release highlights (
> http://www.nvidia.com/object/linux_display_ia32_1.0-6106.html ):
>
> - Added a new Xv adaptor on GeForce4 and GeForce FX which uses the 3D
> engine to do Xv PutImage requests.
Note that this is in addition to the hardware overlay. There are
advantages to the hardware overlay hardware which make it preferable for
high quality video:
1. It is dedicated hardware optimized for video playback: colour
conversion filters and scalers are better optimized for this task
2. Overlay hardware always page flips on retrace so it never
experiences tearing
For these reasons it is important to keep around this functionality.
-Billy
From dilinger at voxel.net Sat Jul 10 16:22:53 2004
From: dilinger at voxel.net (Andres Salomon)
Date: Sat Jul 10 16:23:00 2004
Subject: [Xorg] tla migration
Message-ID: <1089501773.12812.5.camel@spiral.internal>
Hi Daniel,
I noticed in
<http://freedesktop.org/pipermail/xorg/2004-July/001378.html>, you
mentioned a tla-to-cvs gateway. I'd like to point out archzoom, which
should obviate the need for such a thing. The software can be found
here: <http://migo.sixbit.org/software/archzoom/>; I have the current
release (0.2.3) running on
<http://sloth.voxel.net/~dilinger/archzoom.cgi>, and the author has his
current development release running on his site. The unenlightened
(*g*) could simply go to archzoom and download a tarball of the latest
dev tree, if they don't want to (or can't) do a tla get. Note that the
feature is only in the dev tree; it's not in 0.2.3.
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/55d62a25/attach
ment.pgp
From andy at nospam.com Sat Jul 10 20:45:06 2004
Date: Sat Jul 10 20:37:23 2004
Subject: [Xorg] Re: X on OpenGL
In-Reply-To: <E1Bj9wd-0006IW-J9@evo.keithp.com>
Message-ID: <40F0B7C2.8080500@nospam.com>
> X has been implemented on many systems without direct pixel access; as
> long as the system provides the basic pixel manipulations necessary for
> the core (and Render) protocols, we're all set. And, as ajax says, we can
> always use glReadPixels
Quartz Extreme, it turns out, uses OpenGL extensively. Depending
on how exactly Quarz Extreme uses it (am reading
http://www.udnimweb.de/Texte/sg2002bof_apple.pdf right now), I
guess that would vindicate the window manager on top of OpenGL
approach to some degree.
I certainly would have to defer to the judgement of those who are
more familiar with the API and the its implementation efficiency on
different cards, but considering how ironic the fact that it is an
API which was expressly developed to rely on an external 2D window
manager and is now being used to implement one itself, I believe
many would need more convincing as to its appropriateness.
--
Date: Sat Jul 10 20:56:01 2004
In-Reply-To: <40F0B7C2.8080500@nospam.com>
Microsoft is doing the same thing for their Longhorn release except
they use Direct3D instead of OpenGL.
Linux is going to be last man to the party if we don't speed things up.
--- Andy Sy <andy@nospam.com> wrote:
> Quartz Extreme, it turns out, uses OpenGL extensively. Depending
> on how exactly Quarz Extreme uses it (am reading
> http://www.udnimweb.de/Texte/sg2002bof_apple.pdf right now), I
> guess that would vindicate the window manager on top of OpenGL
> approach to some degree.
>
> I certainly would have to defer to the judgement of those who are
> more familiar with the API and the its implementation efficiency on
> different cards, but considering how ironic the fact that it is an
> API which was expressly developed to rely on an external 2D window
> manager and is now being used to implement one itself, I believe
> many would need more convincing as to its appropriateness.
>
>
>
>
>
> --
> reply to: a n d y @ n e t f x p h . c o m
>
> _______________________________________________
> xorg mailing list
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From idr at us.ibm.com Sat Jul 10 21:02:33 2004
Date: Sat Jul 10 21:03:08 2004
In-Reply-To: <20040710020010.GI12023@fooishbar.org>
<20040710020010.GI12023@fooishbar.org>
Message-ID: <40F0BBD9.1040502@us.ibm.com>
Daniel Stone wrote:
> On Fri, Jul 09, 2004 at 12:34:29PM -0700, Eric Anholt wrote:
>
>>- If we move the new fields in PixmapRec to the end, we shouldn't have
>>any binary compat issues, because nobody should be statically allocating
>>PixmapRecs (since they wouldn't have the privates), or at least if they
>>do, the rest of the server shouldn't be seeing them.
>
> You can keep binary-compat if you add new members to the end of
> structures, yes.
Unless those structures are used as arrays. So, if you have:
struct foo array_of_foo[100];
struct foo can pretty much never change. I've had to work around things
like that in DRI-land a couple of times. It's not fun, not fun at all!
Date: Sat Jul 10 22:34:23 2004
<40F0B7C2.8080500@nospam.com>
Message-ID: <E1BjWyX-00079a-2s@evo.keithp.com>
> but considering how ironic the fact that it is an
I agree, the proof will be in the pudding.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/73006d43/attach
ment.pgp
Date: Sat Jul 10 22:36:23 2004
In-Reply-To: Your message of "Sat, 10 Jul 2004 21:02:33 PDT."
<40F0BBD9.1040502@us.ibm.com>
Message-ID: <E1BjX0V-00079q-A2@evo.keithp.com>
Around 21 o'clock on Jul 10, Ian Romanick wrote:
> Unless those structures are used as arrays. So, if you have:
>
> struct foo array_of_foo[100];
>
> struct foo can pretty much never change. I've had to work around things
> like that in DRI-land a couple of times. It's not fun, not fun at all!
Fortunately, I think we're safe with Pixmaps -- there's already an opaque
creation function under control of DIX and arrays of pixmaps aren't
supported by that API.
I'm confident that this hack will work for any X server using pixmap
privates.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040710/6caddc1a/attach
ment.pgp
Date: Sun Jul 11 02:18:29 2004
Subject: [Xorg] [xlibs] libXp
Message-ID: <40F105D7.5010003@toya.net.pl>
I've made an autotooling patch [1] for libXp. It's not ideal, probably
the automake autoadded files are just plain wrong but it works. :)
Before you ask: xprint (from mozdev.org) does not provide any libs.
(only xprint libs & headers I could find were in the monolithic tree)
[1]
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/libXp-autotools.patch?rev=1.1
--
Regards,
Jakub Piotr C?apa
From sandmann at daimi.au.dk Sun Jul 11 04:04:13 2004
Date: Sun Jul 11 04:04:19 2004
In-Reply-To: <E1Bj0zm-00067q-5T@evo.keithp.com>
References: <E1Bj0zm-00067q-5T@evo.keithp.com>
Message-ID: <ye8y8lq3ivm.fsf@ec03.daimi.au.dk>
Keith Packard <keithp@keithp.com> writes:
> I'm having trouble getting Background == None windows to work
> right with Composite. The problem is that when these windows
> are mapped, you get garbage contents for the backing pixmap.
>
> Background == None windows are for two reasons:
>
> 1) To avoid flashing a background pixel which will
> immediately be replaced by "real" contents.
>
> 2) To capture an image of the screen inside the window
>
> I submit that case 1) is a more "legitimate" usage as 2) breaks in the
> presense of different visuals in any case. So, it's important to
> get case 1) right while still letting case 2) do something
> reasonable.
Case 2 is legitimate if the visuals are the same. There are also good
reasons an application could do it. For example to move a subwindow
without flicker you can unset the background of both the window and
its parent, set the bitgravity of the window to static, then move the
window with two XMoveResizeWindow(), then use one or more XCopyArea()
to move the pixels, then reset the backgrounds.
I doubt any applications actually do this, but they could. The
protocol spec is unambiguous that depending on this is allowed for
windows with matching visuals.
> For case 1) (used for menus and window manager frames), it seems
> like the right solution is to avoid painting the window at all
> until the application has managed to fill it entirely with the
> correct content. That would require Damage to be modified to let the
> application know when the window was completely painted, probably by
> adding a boolean to the damage event to pass that information along.
>
> However, when you create a Damage structure for a window, it is
> initialized to the borderClip for that window; if the window is mapped
> (and it often is, even for new windows because applications are pretty
> quick to create/map menus) then the whole window ends up damaged, even
> though it hasn't painted anything yet. I don't see how to fix that --
> the new Damage would have no context to know whether the bits in the
> window were painted by the application or not.
>
> However, we can easily solve case 2) -- just copy the screen area to the
> backing pixmap when the window is mapped. If the compositing manager is
> doing anything weird with the windows, you may get strange looking results
> though -- any shadows will be painted around the "window", even though
> that "window" was filled with bits from the screen underneath it.
To be compatible with the current protocol the screen area needs to be
copied in the case of reszing a window too. Why not simply copy the
contents and not generate a DamageNotify? Logically the window is not
damaged as the application has not painted anything.
The compositing manager can hold the fancy stuff until it sees a
DamageNotify. If the painting application is double buffering, then
the first painting operation will be a complete paint, but as you say
below, Composite can probably not fix all tearing issues by itself
anyway.
> I guess the right solution is to implement the trivial fix for 2) and then
> work on ICCCM extensions for applications to communicate with the
> compositing manager about window painting state. Those extensions are
> required to avoid screen artifacts in other cases, so I guess it's not so
> bad that we need them for menus as well.
I agree with this, although synchronous override redirects as
suggested in the 'Why X is Not Our Ideal Window System' paper would
also be helpful in making mapping managed windows flicker less.
S?ren
From sandmann at daimi.au.dk Sun Jul 11 04:29:10 2004
Date: Sun Jul 11 04:29:58 2004
In-Reply-To: <E1BjA6N-0006KU-Ab@evo.keithp.com>
Message-ID: <ye8u0we3hq1.fsf@ec03.daimi.au.dk>
Keith Packard <keithp@keithp.com> writes:
> Around 23 o'clock on Jul 9, Adam Jackson wrote:
>
> > It might be more accurate to say that the goal is to make the X
> > server a DRI client rather than an OpenGL app.
>
> While that would be possible, that's not my goal -- if GL is available, I'd
> rather just use that for the driver API. We may want a few extensions, but
> the X server should be able to run on plain unextended GL. David Reveman
> and Peter Nilsson show us with Glitz just how feasible this is; glitz
> provides essentially all of the Render semantics on GLX and AGL (with WGL
> support coming soon).
I am not convinced that OpenGL has everything that applications will
need. Some things I don't see how to support:
- vblank notification
OpenGL doesn't deal with this at all. Applications will want a Sync
counter to block on. To do that the server needs to be notified when
vblank starts. Ideally it would be possible to get notifications when
the beam reaches a given scanline.
- mode setting
Changing the mode of hardware Ideally the graphics backend could
change the mode by itself. Seen from inside the X server the API could
look like
ListOfModes ListModes ();
SetMode ();
SetModeChangedNotification (callback)
The idea is that the X server would register a callback that gets
called when the mode changes. It does everything it has to do in
response to that callback. If the server itself wants a different
mode, it calls SetMode() and if the mode setting succeeds, the
callback gets called.
This should be enough that things like XNest can just be another piece
of 'hardware'.
- reading pixels out of the framebuffer
GetImage needs to be supported, and I'd hope that we could do better
than just synchronize with the hardware, then read the pixels. Some
cards can DMA pixels to main memory. The ideal API would be
GetPixels (callback)
so that the X server could go on doing other stuff until the pixels
arrived from the card.
- breadcrumb
To do good-looking animations, applications will want to know when a
given request is actually completed by the graphics hardware. So the
API should support that.
- gamma correct compositing
Really good-looking antialiasing will require gamma correct
compositing. Can OpenGL do this?
A common theme for these things is that it has to be integrated with
the X server's select() loop. Basically the driver API needs to be
able to generate events, and OpenGL doesn't really support that.
So I would like to propose that there is an abstraction layer on top
of OpenGL that has support for these things and also knows about the X
server select() loop.
S?ren
Date: Sun Jul 11 06:16:40 2004
25 Aug means to release a beta preety soon?
When are we going into code freeze?
should we brench into release and continue to advance in the tree?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Fri, 9 Jul 2004, Eric Anholt wrote:
> Here are a few notes I'm writing down from the release call, in case we
> don't get minutes. I wasn't paying attention to who said what, so these
> are just my impressions/conclusions from the call and are not complete
> in any way.
>
> First topic was .so modules:
> - keithp explained the debrix work on making the server use .so
> modules. We should be able to produce .so modules that retain
> cross-platform compatibility for anything using ELF by using the libc
> wrapper, as long as the modules avoid certain hazardous functions
> (setjmp/longjmp)
> - debrix folks (Daniel Stone, Adam Jackson) have made a lot of progress
> on autotooling the x server but have found sticky issues with modules
> involving references to global symbols. They've been fixed in that
> tree, mostly, but this may prove to be a hazard for vendors moving to
> .so modules
> - We should make our modules as .so, which gives us more architecture
> support and debugging ability, but retain the old loader if it proves
> difficult to make the switch fully. We could also take vendors' .a
> modules they produce and convert them to .so using ld probably.
> - Has anyone tested .so modules cross-platform? Nobody on the call at
> least. anholt was volunteered for testing.
>
> Modularizing the build:
> - keithp had volunteered, eich had volunteered to help, but progress has
> stalled due to lack of time.
> - keithp doesn't have time until at least 3 weeks from now
> - Many, but by no means all libraries have been autotooled in the xlibs
> project, so we have a basis to work from
> - Modularizing of xorg can be done incrementally. First, rearrange
> includes directory to make modular while retaining imake build, which
> allows the libs to be done. Later the xserver autotooling can be
> brought in, at which point the imake build can be left to rot.
>
> Composite:
> - anholt has attempted to do Composite support for XAA, which was never
> completed, but the first thing to do would be to make a wrapper at the
> miext layer that retained binary compatibility.
> - If we move the new fields in PixmapRec to the end, we shouldn't have
> any binary compat issues, because nobody should be statically allocating
> PixmapRecs (since they wouldn't have the privates), or at least if they
> do, the rest of the server shouldn't be seeing them.
> - anholt concerned about doing Composite wrapper because of lack of
> experience, eich suggested he could. (I'm attempting it anyway)
>
> Release:
> - Timing of next release: two months? end of year? next year?
> - Proposed that we release in time for Fedora Core 3
> - FC3 schedule would require a release by Sep 6?
> - Proposed that we target having a release by Aug 25
> - General agreement found.
> - What should be in release? Composite/Damage/Fixes found general
> agreement. What else? Call put out to xorg@
>
> --
>
>
>
> _______________________________________________
> xorg mailing list
>
Date: Sun Jul 11 06:17:02 2004
On Sat, 10 Jul 2004, [ISO-8859-2] Jakub Piotr C?apa wrote:
> > On Friday 09 July 2004 14:52, Jakub Piotr C?apa wrote:
> >
> development but need to rebuild some software with xlibs first. :)
>
> I was asking about a longer period of time. Is first debrix release
> expected this year or is monolithic tree planned to be the main tree for
> next 2 years? :)
And what about the move to XCB?
By their page I uderstand they are preety much done,
is there a general time table? or what need to be done?
Ely
From matthew at alledora.co.uk Sun Jul 11 08:51:54 2004
From: matthew at alledora.co.uk (Matthew Walton)
Date: Sun Jul 11 08:52:38 2004
In-Reply-To: <ye8u0we3hq1.fsf@ec03.daimi.au.dk>
<ye8u0we3hq1.fsf@ec03.daimi.au.dk>
Message-ID: <40F1621A.9080401@alledora.co.uk>
Soeren Sandmann wrote:
> - vblank notification
>
> OpenGL doesn't deal with this at all. Applications will want a Sync
> counter to block on. To do that the server needs to be notified when
> vblank starts. Ideally it would be possible to get notifications when
> the beam reaches a given scanline.
Okay, I know very little about these things (I'm only really on this
list because I'm interested in the whole project, and might even learn a
few things here and there), but isn't relying on things like vblank a
bit ill-advised in this age where we're increasingly going to be talking
to LCD panels over a DVI link? Or does it simulate all that (what I
would consider to be) completely unnecessary analogue stuff which only
exists because of the design of the common or garden CRT?
If it does, urgh. Presumably if it's being used in current X systems, it
must be, as I'm using X happily on an LCD plugged into the DVI port of
my Radeon 9800 Pro. Maybe things haven't been moving on as fast as I
thought...
Date: Sun Jul 11 09:22:14 2004
Subject: [Xorg] Server side widgets
Hey,
latly I saw quite a few flame wars about server side widgets,
People from projects like y-windows and onyx claim for performance
improvments and nicer cleaner implementations,
as well as that X doesn't support it from the plain reason it is old.
I got the impression it was a design descision, which lead to many
diffrent tool kits.
My question is, why did X chose not to use server side widgets (if it was
ever concidered)?
and what other advantages/disadvatages it has?
This is really not ment as a flame question, just honest will to know:)
Ely Levy
System group
Hebrew University
Jerusalem Israel
Date: Sun Jul 11 09:38:36 2004
In-Reply-To: Your message of "11 Jul 2004 13:04:13 +0200."
<ye8y8lq3ivm.fsf@ec03.daimi.au.dk>
Message-ID: <E1BjhLK-0007k7-0e@evo.keithp.com>
Around 13 o'clock on Jul 11, Soeren Sandmann wrote:
> I doubt any applications actually do this, but they could. The
> protocol spec is unambiguous that depending on this is allowed for
> windows with matching visuals.
Right, but the case I'm most concerned with is the top-level case where
applications can't rely upon the visuals of underlying windows.
Within an application, presumably it would know whether compositing was
enabled for any of its subwindows (implicit compositing happens only
across different visual types).
> To be compatible with the current protocol the screen area needs to be
> copied in the case of reszing a window too. Why not simply copy the
> contents and not generate a DamageNotify? Logically the window is not
> damaged as the application has not painted anything.
That certainly seems like the most reasonable plan. The trouble is with
the 'not generate a DamageNotify' event. Right now, an application will
create and map a window *before* the compositing manager gets notified
that the new window exists. Therefore, the Damage object doesn't get
allocated until after the window is already mapped on the screen.
Currently, Damage objects are automatically filled with the window border
clip when created -- this avoids lots of race conditions in normal usage,
and if the window had actually painted anything (even with a background
other than 'None'), it would be necessary. I don't know how to avoid
damage in the right cases -- it seems like the server would have to track
the affected area *in advance* of any damage object being created.
Perhaps we need some implicit damage creation mechanism, just as we have
an implicit composite creation system.
> I agree with this, although synchronous override redirects as
> suggested in the 'Why X is Not Our Ideal Window System' paper would
> also be helpful in making mapping managed windows flicker less.
Compositing *can* eliminate all flicker if we come up with conventions for
applications and window managers to update at the 'right' times. Perhaps
we need to develop some preliminary mechansism and see whether additions
or changes to the composite or damage extensions are needed to make
that reasonably efficient.
Thanks much for your comments and suggestions!
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040711/2c2cca8c/attach
ment.pgp
From roland.mainz at nrubsig.org Sun Jul 11 09:46:15 2004
Date: Sun Jul 11 09:47:06 2004
Message-ID: <40F16ED7.6425479D@nrubsig.org>
Ely Levy wrote:
> latly I saw quite a few flame wars about server side widgets,
> People from projects like y-windows and onyx claim for performance
> improvments and nicer cleaner implementations,
> as well as that X doesn't support it from the plain reason it is old.
> I got the impression it was a design descision, which lead to many
> diffrent tool kits.
>
> My question is, why did X chose not to use server side widgets (if it was
> ever concidered)?
Well, you will need something like a server-side language to get the
widgets working. DPS(=Display PostScript) was capable to do server-side
widgets - but somehow DPS was lost deep in hell.
Today such a project will likely "die" in the flamewar "which language
should be used: JAVA, Perl, PostScript, TCL, bash(ouch!) etc. ..." ...
=:-)
This issue could be solved via a platform-independent bytecode
interpreter... but I still doubt that something like server-side widgets
will ever become popular - it's a radically different approach compared
to today's toolkits and people don't like to rewrite/invent the stuff
from scratch if the "old ways" still work.
> and what other advantages/disadvatages it has?
First things which come in mind: How can I debug those widgets ? How can
I stop one widget from screwing up the whole server (e.g. grab CPU, grab
all memory) ?
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 09:51:08 2004
In-Reply-To: Your message of "11 Jul 2004 13:29:10 +0200."
Message-ID: <E1BjhX6-0007kS-29@evo.keithp.com>
Around 13 o'clock on Jul 11, Soeren Sandmann wrote:
> I am not convinced that OpenGL has everything that applications will
> need. Some things I don't see how to support:
It's important to think of OpenGL as just the rendering back-end, not the
whole X server architecture. In particular, OpenGL requires external
device configuration mechanisms which are system-dependent (GLX, AGL, WGL).
And, OpenGL doesn't provide much in the way of input device support, so
we'll want to add our own for that.
> - mode setting
>
> Changing the mode of hardware
We're already talking about moving this to an external library which can
be shared by all graphics applications; my assumption here is that the
system-dependent pieces for a 'Gl-solo' based X server would include an
interface to this library.
I don't have a solid idea about how that library should be constructed;
whether the X server should be in charge of mode selection at any level or
whether it should just react to externally controlled events.
> - reading pixels out of the framebuffer
>
> GetImage needs to be supported, and I'd hope that we could do better
> than just synchronize with the hardware, then read the pixels. Some
> cards can DMA pixels to main memory.
The GL API isn't required to be lame. I believe the closed-source nVidia
driver uses DMA in this case, but the bandwidth of that operation is only a
small factor faster than the bandwidth of reading data with the CPU as it
has to transit AGP space, which (I believe) involves manual CPU cache
poisoning or uncached accesses.
> - breadcrumb
>
> To do good-looking animations, applications will want to know when a
> given request is actually completed by the graphics hardware. So the
> API should support that.
Yeah, this would be nice; we could manage schedulin the hardware better
with this as well.
> - gamma correct compositing
>
> Really good-looking antialiasing will require gamma correct
> compositing. Can OpenGL do this?
Some OpenGL hardware does support this, but most does not at the current
time. Certainly new programmable hardware should be able to manage this,
and I think the GL api exposes enough capability to suppor it.
> So I would like to propose that there is an abstraction layer on top
> of OpenGL that has support for these things and also knows about the X
> server select() loop.
The open source GL drivers are mutable, so we can experiment with them and
push changes into closed source drivers as well. The key is to figure out
how to make this all work; the fact that we're drawing to the screen
through the OpenGL API doesn't really change much here.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040711/20b12072/attach
ment-0001.pgp
Date: Sun Jul 11 09:54:08 2004
In-Reply-To: Your message of "Sun, 11 Jul 2004 16:51:54 BST."
<40F1621A.9080401@alledora.co.uk>
Message-ID: <E1BjhaA-0007kp-T9@evo.keithp.com>
Around 16 o'clock on Jul 11, Matthew Walton wrote:
> but isn't relying on things like vblank a
> bit ill-advised in this age where we're increasingly going to be talking
> to LCD panels over a DVI link?
DVI links are serial and repaint every pixel on the screen each frame, so
they do have an implicit 'retrace', even though the LCD screen itself holds
each pixel steady.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040711/7ba80f08/attach
ment.pgp
From krh at bitplanet.net Sun Jul 11 10:14:18 2004
From: krh at bitplanet.net (=?ISO-8859-1?Q?Kristian_H=F8gsberg?=)
Date: Sun Jul 11 10:15:54 2004
Message-ID: <40F1756A.80103@bitplanet.net>
Kevin E Martin wrote:
>
>
I sent a patch to remove legacy keyboard support in favour of the new,
modularized kbd keyboard driver. Egbert suggested that the way to go
with this was to deprecate the legacy driver and not compile it by
default for a while. After that the legacy driver could hopefully be
removed. Would it be appropriate to take this firste step with the next
release? The release after that could then remove the legacy driver.
Comments?
Kristian
Date: Sun Jul 11 10:16:35 2004
In-Reply-To: <40F16ED7.6425479D@nrubsig.org>
<40F16ED7.6425479D@nrubsig.org>
On Sun, 11 Jul 2004, Roland Mainz wrote:
> Ely Levy wrote:
> > latly I saw quite a few flame wars about server side widgets,
> > People from projects like y-windows and onyx claim for performance
> > improvments and nicer cleaner implementations,
> > as well as that X doesn't support it from the plain reason it is old.
> > I got the impression it was a design descision, which lead to many
> > diffrent tool kits.
> >
> > My question is, why did X chose not to use server side widgets (if it was
> > ever concidered)?
>
> Well, you will need something like a server-side language to get the
> widgets working. DPS(=Display PostScript) was capable to do server-side
> widgets - but somehow DPS was lost deep in hell.
> Today such a project will likely "die" in the flamewar "which language
> should be used: JAVA, Perl, PostScript, TCL, bash(ouch!) etc. ..." ...
> =:-)
I think ywindows onyx persco just used simple c/c++?
What the advantage of bytecode?
> This issue could be solved via a platform-independent bytecode
> interpreter... but I still doubt that something like server-side widgets
> will ever become popular - it's a radically different approach compared
> to today's toolkits and people don't like to rewrite/invent the stuff
> from scratch if the "old ways" still work.
Yea, but if that is the reason, moving forward should happen at some
point.
> > and what other advantages/disadvatages it has?
>
> First things which come in mind: How can I debug those widgets ? How can
> I stop one widget from screwing up the whole server (e.g. grab CPU, grab
> all memory) ?
Write them well?:)
actually i saw it happen in client side as well, making certain
clients go berserk and take all CPU,
so there isn't much diffrance IMOH.
Ely
From elanthis at awesomeplay.com Sun Jul 11 10:20:14 2004
Date: Sun Jul 11 10:20:18 2004
Message-ID: <1089566414.23027.5.camel@stargrazer.home.awesomeplay.com>
On Sun, 2004-07-11 at 19:22 +0300, Ely Levy wrote:
> Hey,
> latly I saw quite a few flame wars about server side widgets,
> People from projects like y-windows and onyx claim for performance
> improvments and nicer cleaner implementations,
> as well as that X doesn't support it from the plain reason it is old.
> I got the impression it was a design descision, which lead to many
> diffrent tool kits.
>
> My question is, why did X chose not to use server side widgets (if it was
> ever concidered)?
>
> and what other advantages/disadvatages it has?
First, it's policy in the server. X is designed to have zero policy,
and to let the users over-ride it.
Second, how do users modify those widgets, such as with themes? The
server still generally requires root access; do you really want users to
be able to modify the code that runs there?
Third, speaking of root, do you really want all that complex code in
such a process? The more code you have, the more potential bugs and
security holes.
Fourth, a vast array of applications use custom widgets. How would
those work? You'd either need to still allow client-side drawing (and
then all the client-side support to mimic the themes and styles of the
server-side widgets) or let clients upload code/scripts to the (again)
root-running server.
Fifth, how do you advance the state of the art? We started off with
things like Xt, Motif, etc. GTK+/Qt are much better than those in so
many ways. They probably couldn't have developed so quickly and with so
much innovation if they were limited to using a pre-defined protocol for
server-side widgets, and had to run in the display server.
Sixth, who has _proven_ they're actually faster in the server?
Especially for more complex widgets? Imagine something like the tree
view in GTK+ - the server would need access to all that information so
that if the user scrolls around, it knows what to display. No way that
could be faster in the server.
>
> This is really not ment as a flame question, just honest will to know:)
>
>
> Ely Levy
> System group
> Hebrew University
> Jerusalem Israel
>
>
>
> _______________________________________________
> xorg mailing list
>
Date: Sun Jul 11 10:28:14 2004
Message-ID: <40F1786F.46F5111D@nrubsig.org>
Ely Levy wrote:
> > > latly I saw quite a few flame wars about server side widgets,
> > > People from projects like y-windows and onyx claim for performance
> > > improvments and nicer cleaner implementations,
> > > as well as that X doesn't support it from the plain reason it is old.
> > > I got the impression it was a design descision, which lead to many
> > > diffrent tool kits.
> > >
> > > My question is, why did X chose not to use server side widgets (if it was
> > > ever concidered)?
> >
> > Well, you will need something like a server-side language to get the
> > widgets working. DPS(=Display PostScript) was capable to do server-side
> > widgets - but somehow DPS was lost deep in hell.
> > Today such a project will likely "die" in the flamewar "which language
> > should be used: JAVA, Perl, PostScript, TCL, bash(ouch!) etc. ..." ...
> > =:-)
> I think ywindows onyx persco just used simple c/c++?
Think about remote X11: Client is a Cray SV1 (vector machine), server is
Xorg server on Linux/x86... how to you want to run the C++ code of a
Cray in the Xserver ? :)
> What the advantage of bytecode?
Having a platform-independent, low-level language and a way to run a
scheduler to allow fair CPU usage by all widgets regardless how the
widget code was designed/written.
[snip]
> Write them well?:)
> actually i saw it happen in client side as well, making certain
> clients go berserk and take all CPU,
> so there isn't much diffrance IMOH.
Sure, but there is always the way to "kill -9 ${pid_of_berserk_client}".
You really do not want to kill the whole server just because one client
got rabies.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 10:30:36 2004
Subject: [Xorg] Understand Composite and Damage Extenstions
Message-ID: <E1Bji9l-0002Ph-00@mailgate.rz.uni-karlsruhe.de>
I study the composite extension, because I will use it later and may I will
do some modification in it.

When I client redirect a window the extension will call
compalloc.c:compRedirectWindow() this function then should move that window
to an off-screen. Where is this off-screen saved (in which C structure)? I
don't figured it from the code of that function.
To understand all the stuff let me make a simple example:

1- a client create a window at 100,100.
2- Then it maps that window.
3- Another client receives a mapRequest, and then it redirects (as
manual) it to off-screen.
4- The first client paint to the window as normal.
As this window has been moved to off-screen nothing will be displayed unless
the other client do that.

How Paint functions will make their work on the off-screen not as normal at
the screen directly?

The new graphics card has framebuffer. When a client create a window X
server create for it window structure which save the position of the window
on framebuffer. When painting xserver will paint directly to the framebuffer
via GC operations, which am most hardware dependent.
How those work when a window is redirect? I can't figure that from the code
directly.

I will be glad if someone gives me sometime to describe this.

Amir
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040711/c704b2ac/attachm
ent.htm
From idr at us.ibm.com Sun Jul 11 10:31:54 2004
Date: Sun Jul 11 10:32:45 2004
In-Reply-To: <ye8u0we3hq1.fsf@ec03.daimi.au.dk>
Message-ID: <40F1798A.6090505@us.ibm.com>
> - vblank notification
>
> OpenGL doesn't deal with this at all. Applications will want a Sync
> counter to block on. To do that the server needs to be notified when
> vblank starts. Ideally it would be possible to get notifications when
> the beam reaches a given scanline.
There are OpenGL extensions to support this functionality, and several
of the open-source drivers support some of them. See the following:
http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_swap_method.txt
http://oss.sgi.com/projects/ogl-sample/registry/OML/glx_sync_control.txt
http://oss.sgi.com/projects/ogl-sample/registry/SGI/swap_control.txt
http://oss.sgi.com/projects/ogl-sample/registry/SGI/video_sync.txt
If they don't cover all the functionality that apps need, we can define
our own extensions that do.
Date: Sun Jul 11 10:33:27 2004
Subject: Xserver needs to run as "root" on Linux / was: Re: [Xorg] Server side
widgets
<1089566414.23027.5.camel@stargrazer.home.awesomeplay.com>
Message-ID: <40F179BF.A788B321@nrubsig.org>
Sean Middleditch wrote:
[snip]
> Third, speaking of root, do you really want all that complex code in
> such a process? The more code you have, the more potential bugs and
> security holes.
This is _ONLY_ a problem of the Linux Xserver. Solaris and other Unices
run their Xserver under plain user accounts. IMHO there should be
_urgendly_ some work on removing the requirement of running the Xserver
as "root". Things like a seperate group (e.g. "X11", "Xserver") +
setting ACLs on the neccesary /dev entries comes in mind... or turning
the drivers into kernel modules (AFAIK Solaris Xsun does it that way).
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 10:51:31 2004
In-Reply-To: <1089566414.23027.5.camel@stargrazer.home.awesomeplay.com>
On Sun, 11 Jul 2004, Sean Middleditch wrote:
> On Sun, 2004-07-11 at 19:22 +0300, Ely Levy wrote:
> > Hey,
> > latly I saw quite a few flame wars about server side widgets,
> > People from projects like y-windows and onyx claim for performance
> > improvments and nicer cleaner implementations,
> > as well as that X doesn't support it from the plain reason it is old.
> > I got the impression it was a design descision, which lead to many
> > diffrent tool kits.
> >
> > My question is, why did X chose not to use server side widgets (if it was
> > ever concidered)?
> >
> > and what other advantages/disadvatages it has?
>
> First, it's policy in the server. X is designed to have zero policy,
> and to let the users over-ride it.
Simple as possible, but I still featurefull
> Second, how do users modify those widgets, such as with themes? The
> server still generally requires root access; do you really want users to
> be able to modify the code that runs there?
>
> Third, speaking of root, do you really want all that complex code in
> such a process? The more code you have, the more potential bugs and
> security holes.
Loading a theme is not really running code there,
but you are right, the xserver on linux need to be fixed so it wouldn't
need root access to run.
> Fourth, a vast array of applications use custom widgets. How would
> those work? You'd either need to still allow client-side drawing (and
> then all the client-side support to mimic the themes and styles of the
> server-side widgets) or let clients upload code/scripts to the (again)
> root-running server.
Backward compatibilty is always a problem,
You won't get anywhere without breaking it from time to time,
Both solutions you offered seemed to work though, still allowing
client-side drawing would work for a while. and as I said before
the fact xserver runs as root needs to be fixed anyhow.
(I think it's not like that on some other systems?)
> Fifth, how do you advance the state of the art? We started off with
> things like Xt, Motif, etc. GTK+/Qt are much better than those in so
> many ways. They probably couldn't have developed so quickly and with so
> much innovation if they were limited to using a pre-defined protocol for
> server-side widgets, and had to run in the display server.
True,
But maybe we got to the point where things are more stable?
I know fd.o is making a lot of effords making GTK/Qt (gnome/kde)
agree on certain standards, that can be yet another one.
other option like you said is to make it in extandable way
following the long X tradition:)
(uploading bytecode to the server?)
> Sixth, who has _proven_ they're actually faster in the server?
> Especially for more complex widgets? Imagine something like the tree
> view in GTK+ - the server would need access to all that information so
> that if the user scrolls around, it knows what to display. No way that
> could be faster in the server.
I think both ywindows and fresco debated about that,
I guess what pushed it is less the speed which would probebly won't
make that much diffrent, but the fact it's uniform and easier to use.
http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/MarkThomas.pdf
Ely
From matthieu.herrb at laas.fr Sun Jul 11 10:55:36 2004
Date: Sun Jul 11 10:56:06 2004
Subject: Xserver needs to run as "root" on Linux / was: Re: [Xorg] Server
side widgets
In-Reply-To: <40F179BF.A788B321@nrubsig.org>
References: <Pine.LNX.4.56.0407111916510.6014@grok.cs.huji.ac.il> <1089566
414.23027.5.camel@stargrazer.home.awesomeplay.com>
<40F179BF.A788B321@nrubsig.org>
Message-ID: <40F17F18.5080700@laas.fr>
Roland Mainz wrote:
> Sean Middleditch wrote:
> [snip]
>
>>Third, speaking of root, do you really want all that complex code in
>>such a process? The more code you have, the more potential bugs and
>>security holes.
>
>
> This is _ONLY_ a problem of the Linux Xserver. Solaris and other Unices
> run their Xserver under plain user accounts. IMHO there should be
> _urgendly_ some work on removing the requirement of running the Xserver
> as "root". Things like a seperate group (e.g. "X11", "Xserver") +
> setting ACLs on the neccesary /dev entries comes in mind... or turning
> the drivers into kernel modules (AFAIK Solaris Xsun does it that way).
>
This cannot be changed without requiring the exising systems to be
upgraded to a kernel that doesn't require root to access to the hardware
(I/O ports and /dev/mem). I don't know for linux, but for *BSD it's not
just a matter of permissions on /dev entries.
Giving away these permissions to a specific uid or group also may have
some unforseen effects, I'm not sure.
Root privileges are currently also used to create the log file in
/var/log. This needs to be addressed too (use syslog ?)
The privilege separation code and the systrace poolicy I developped for
the XFree86 server on OpenBSD (see
<ftp://ftp.laas.fr/pub/ii/matthieu/xf86-sec.pdf>) is interesting in
showing were root privileges are actually used in XFree86.
--
Matthieu
Date: Sun Jul 11 10:56:57 2004
In-Reply-To: <40F1786F.46F5111D@nrubsig.org>
<40F1786F.46F5111D@nrubsig.org>
On Sun, 11 Jul 2004, Roland Mainz wrote:
> Ely Levy wrote:
> Think about remote X11: Client is a Cray SV1 (vector machine), server is
> Xorg server on Linux/x86... how to you want to run the C++ code of a
> Cray in the Xserver ? :)
Running a code at the server?
the xserver has the widget you just call it,
you don't pass code?
> > What the advantage of bytecode?
>
> Having a platform-independent, low-level language and a way to run a
> scheduler to allow fair CPU usage by all widgets regardless how the
> widget code was designed/written.
Yea, In the way you are thinking of, which is actually preety cool,
this would be a major advantage:)
> [snip]
> > Write them well?:)
> > actually i saw it happen in client side as well, making certain
> > clients go berserk and take all CPU,
> > so there isn't much diffrance IMOH.
>
> Sure, but there is always the way to "kill -9 ${pid_of_berserk_client}".
> You really do not want to kill the whole server just because one client
> got rabies.
Yea,
I guess you are right,
But still with well written code i don't think it would
happen too often
Ely
Date: Sun Jul 11 11:08:29 2004
side widgets
On Sun, 11 Jul 2004, Matthieu Herrb wrote:
> Roland Mainz wrote:
> > Sean Middleditch wrote:
> > [snip]
> >
> >>Third, speaking of root, do you really want all that complex code in
> >>such a process? The more code you have, the more potential bugs and
> >>security holes.
> >
> >
> > This is _ONLY_ a problem of the Linux Xserver. Solaris and other Unices
> > run their Xserver under plain user accounts. IMHO there should be
> > _urgendly_ some work on removing the requirement of running the Xserver
> > as "root". Things like a seperate group (e.g. "X11", "Xserver") +
> > setting ACLs on the neccesary /dev entries comes in mind... or turning
> > the drivers into kernel modules (AFAIK Solaris Xsun does it that way).
> >
>
> This cannot be changed without requiring the exising systems to be
> upgraded to a kernel that doesn't require root to access to the hardware
> (I/O ports and /dev/mem). I don't know for linux, but for *BSD it's not
> just a matter of permissions on /dev entries.
I think it's diffrent in linux,
but if that what is required I think it's important enough.
> Giving away these permissions to a specific uid or group also may have
> some unforseen effects, I'm not sure.
>
> Root privileges are currently also used to create the log file in
> /var/log. This needs to be addressed too (use syslog ?)
There are other programs who run as non root and use syslog,
like news/mail and ftp deamons.
> The privilege separation code and the systrace poolicy I developped for
> the XFree86 server on OpenBSD (see
> <ftp://ftp.laas.fr/pub/ii/matthieu/xf86-sec.pdf>) is interesting in
> showing were root privileges are actually used in XFree86.
> --
> Matthieu
>
Yea, that sort of cover it:)
Ely
Date: Sun Jul 11 11:32:08 2004
Message-ID: <40F1878E.1374DA5@nrubsig.org>
Ely Levy wrote:
> > Ely Levy wrote:
> > Think about remote X11: Client is a Cray SV1 (vector machine), server is
> > Xorg server on Linux/x86... how to you want to run the C++ code of a
> > Cray in the Xserver ? :)
>
> Running a code at the server?
> the xserver has the widget you just call it,
> you don't pass code?
I doubt this will be fun for the application developers. Just think
about issues like IME, Accessibility etc. IMO something more RISC-like
may be better... much better.
What about allowing JAVA applications run within the Xserver ? The JVM
can run more than one language (see
http://flp.cs.tu-berlin.de/~tolk/vmlanguages.html/) and there are
JAVA-bindings for X11 (see http://sourceforge.net/projects/escher/) ...
we would only need an API that X11 applications can talk to the JVM
(rules: No one comes up with the term "IDL". FORBIDDEN! xx@@@!!!).
> > > What the advantage of bytecode?
> >
> > Having a platform-independent, low-level language and a way to run a
> > scheduler to allow fair CPU usage by all widgets regardless how the
> > widget code was designed/written.
>
> Yea, In the way you are thinking of, which is actually preety cool,
> this would be a major advantage:)
:)
> > > Write them well?:)
> > > actually i saw it happen in client side as well, making certain
> > > clients go berserk and take all CPU,
> > > so there isn't much diffrance IMOH.
> >
> > Sure, but there is always the way to "kill -9 ${pid_of_berserk_client}".
> > You really do not want to kill the whole server just because one client
> > got rabies.
>
> Yea,
> I guess you are right,
> But still with well written code i don't think it would
> happen too often
... but when it happens all hell break loose. Think about AmigaOS -
which had no memory protection etc. 98% of the time everying was fine -
but when one application went mad then the whole OS was screwed.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 11:34:50 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don't support it in
hardware...
Message-ID: <40F18836.5FCF6789@nrubsig.org>
Hi!
----
Is there a way to implement the "Xv" extension on hardware which doesn't
support it (for example Xnest, Xvfb etc.) ?
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 11:38:30 2004
On Sun, 2004-07-11 at 20:51 +0300, Ely Levy wrote:
>
> On Sun, 11 Jul 2004, Sean Middleditch wrote:
> > Fourth, a vast array of applications use custom widgets. How would
> > those work? You'd either need to still allow client-side drawing (and
> > then all the client-side support to mimic the themes and styles of the
> > server-side widgets) or let clients upload code/scripts to the (again)
> > root-running server.
>
> Backward compatibilty is always a problem,
> You won't get anywhere without breaking it from time to time,
> Both solutions you offered seemed to work though, still allowing
> client-side drawing would work for a while. and as I said before
> the fact xserver runs as root needs to be fixed anyhow.
> (I think it's not like that on some other systems?)
You're msising the point. It has nothing to do with backwards
compatibility. It has to do with applications needing custom widgets.
You will never come up with a list of widgets that covers everything
every application needs. In order to support any new or custom widgets
apps may need down the road, you need client-side drawing, and all the
complex machinery and API for client-side theming and such. What point
then is there in the server?
>
> > Fifth, how do you advance the state of the art? We started off with
> > things like Xt, Motif, etc. GTK+/Qt are much better than those in so
> > many ways. They probably couldn't have developed so quickly and with so
> > much innovation if they were limited to using a pre-defined protocol for
> > server-side widgets, and had to run in the display server.
>
> True,
> But maybe we got to the point where things are more stable?
> I know fd.o is making a lot of effords making GTK/Qt (gnome/kde)
> agree on certain standards, that can be yet another one.
> other option like you said is to make it in extandable way
> following the long X tradition:)
> (uploading bytecode to the server?)
The standards have very little to do with how the widgets look or act.
That is entirely something that should never be standardized, because
there is a big reason they act differently in those respects.
ALso, what about any new ideas down the road? Something like Looking
Glass, maybe. Putting things in the server shoots future innovation in
the foot.
>
> > Sixth, who has _proven_ they're actually faster in the server?
> > Especially for more complex widgets? Imagine something like the tree
> > view in GTK+ - the server would need access to all that information so
> > that if the user scrolls around, it knows what to display. No way that
> > could be faster in the server.
>
> I think both ywindows and fresco debated about that,
> I guess what pushed it is less the speed which would probebly won't
> make that much diffrent, but the fact it's uniform and easier to use.
How? Either way, apps just call an API. The application in no way
should care whether the widgets in that API are implemented in the
client-side library or server. Unless they start doing custom widgets
(quite common), in which case the client-side API is much easier.
And the speed _would_ be a huge factor. The server woudl either need
all the information that client has about the client-specific data, or
there would need to be a metric ton of signals/messages going back-and-
forth to keep things updated (i.e., messages requiring round-trips and
thus latency, which just having the client redraw the widget view
wouldn't need to anywhere near the same degree). Either way, you are
going to run no faster, possibly a lot slower, than what we have now...
so why bother? If the only advantages anybody has ever tried to list
for putting widgets server-side isn't true, then putting them server-
side is a pretty goofy thing to do.
>
> http://www.doc.ic.ac.uk/~ajf/Teaching/Projects/Distinguished03/MarkThomas.pdf
>
> Ely
>
> _______________________________________________
> xorg mailing list
>
Date: Sun Jul 11 12:16:30 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don't support
it in hardware...
In-Reply-To: <40F18836.5FCF6789@nrubsig.org>
References: <40F18836.5FCF6789@nrubsig.org>
On Sul, 2004-07-11 at 19:34, Roland Mainz wrote:
> Is there a way to implement the "Xv" extension on hardware which doesn't
> support it (for example Xnest, Xvfb etc.) ?
I guess since nobody can see the display in Xvfb a "correct"
implementation would be to offer Xv overlays that have no-op functions
(and anyone reading back the fb - well its a hardware overlay so you
dont see the data ;))
For Xnest there is certainly nothing preventing it providing you go off
and write enough code. Xnest is an Xwindow, that means the Xv layer of
the master X server is perfectly capable of handling an Xv subwindow in
the Xnest window - you just have to get all the overlay offsets correct
and propogate the functionality.
Date: Sun Jul 11 12:18:41 2004
On Gwe, 2004-07-09 at 18:54, Kevin E Martin wrote:
Unichrome has a couple of funnies - I've committed the fix for
unichrome not actually compiling. There is another bug you can see
with tuxracer's background. I believe looking at other drivers that the
colour clear setting is wrong (it takes the float and multiplies by
255.0 before clamping while the sis driver for example assumes the
passed colours are floats already in 0-255 range).
In general the DRI in Xorg CVS is an order of magnitude superior to the
last Xorg, even allowing for bugs.
Sadly, while I have sis6326 dri building again it won't be ready in time
8)
Date: Sun Jul 11 12:28:41 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don't supportit
in hardware...
Message-ID: <40F194CE.3ACF8370@nrubsig.org>
Alan Cox wrote:
> > Is there a way to implement the "Xv" extension on hardware which doesn't
> > support it (for example Xnest, Xvfb etc.) ?
>
> I guess since nobody can see the display in Xvfb a "correct"
> implementation would be to offer Xv overlays that have no-op functions
> (and anyone reading back the fb - well its a hardware overlay so you
> dont see the data ;))
Dumb question:
I cannot implement "Xv" in a way like Mesa implements GLX for Xvfb (e.g.
push images via XPutImage()), right ?
Are the "Xv" overlays _required_ to leave the underlying framebuffer
contents intact ?
> For Xnest there is certainly nothing preventing it providing you go off
> and write enough code. Xnest is an Xwindow, that means the Xv layer of
> the master X server is perfectly capable of handling an Xv subwindow in
> the Xnest window - you just have to get all the overlay offsets correct
> and propogate the functionality.
What if the underlying Xserver does not support "Xv" ?
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 12:29:02 2004
In-Reply-To: <a728f9f904070712097522297e@mail.gmail.com>
<40E9CF97.8080301@xs4all.nl>
<a728f9f904070712097522297e@mail.gmail.com>
On Mer, 2004-07-07 at 20:09, Alex Deucher wrote:
> > Sort of. The 2D engine has a 4Mbyte limit but the other 4Mbytes can
> > be used for texture ram with the 3d driver patches (not that they
> > actually get textures right yet.. 8))
>
> BTW, where are you or Eric's sis patches? Just curious...
By way of an update I have the sis6326 dri building against the
current DRI and the 2D small patches in a the sis 2D driver. I've
also merged the S3Virge driver although that needs a lot more work
before it'll pull any triangles.
Date: Sun Jul 11 12:30:42 2004
On Sul, 2004-07-11 at 04:55, Jon Smirl wrote:
> Microsoft is doing the same thing for their Longhorn release except
> they use Direct3D instead of OpenGL.
>
> Linux is going to be last man to the party if we don't speed things up.
Can opengl effectively extract 2D scroll/blit - that will matter for
s/w mesa on 2D hardware ?
As to missing the boat, give them 2 or 3 years and OpenGL itself will be
missing the boat in favour of raytracing hardware ;)
Date: Sun Jul 11 12:41:52 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don't
supportit in hardware...
In-Reply-To: <40F194CE.3ACF8370@nrubsig.org>
<40F194CE.3ACF8370@nrubsig.org>
> I cannot implement "Xv" in a way like Mesa implements GLX for Xvfb (e.g.
> push images via XPutImage()), right ?
> Are the "Xv" overlays _required_ to leave the underlying framebuffer
> contents intact ?
Given the 'virtual' frame buffer lacks hardware acceleration for any
Xv functionality if you use null functions apps "work" so you can
test/use them. For any real app it would perform better anyway to
use MITSHM
> > For Xnest there is certainly nothing preventing it providing you go off
> > and write enough code. Xnest is an Xwindow, that means the Xv layer of
> > the master X server is perfectly capable of handling an Xv subwindow in
> > the Xnest window - you just have to get all the overlay offsets correct
> > and propogate the functionality.
>
> What if the underlying Xserver does not support "Xv" ?
If it doesn't support Xv (or I suppose Mesa DRI) then you would again be
better off with the client doing the work
Date: Sun Jul 11 12:47:25 2004
In-Reply-To: <40F194CE.3ACF8370@nrubsig.org>
On Sun, 2004-07-11 at 12:28, Roland Mainz wrote:
> Alan Cox wrote:
> > > Is there a way to implement the "Xv" extension on hardware which doesn't
> > > support it (for example Xnest, Xvfb etc.) ?
> >
> > I guess since nobody can see the display in Xvfb a "correct"
> > implementation would be to offer Xv overlays that have no-op functions
> > (and anyone reading back the fb - well its a hardware overlay so you
> > dont see the data ;))
>
> Dumb question:
> I cannot implement "Xv" in a way like Mesa implements GLX for Xvfb (e.g.
> push images via XPutImage()), right ?
>
> Are the "Xv" overlays _required_ to leave the underlying framebuffer
> contents intact ?
No, most XV implementations paint a color key on the underlying
framebuffer, so you typically don't read back the video if you do a
screenshot, for example.
> > For Xnest there is certainly nothing preventing it providing you go off
> > and write enough code. Xnest is an Xwindow, that means the Xv layer of
> > the master X server is perfectly capable of handling an Xv subwindow in
> > the Xnest window - you just have to get all the overlay offsets correct
> > and propogate the functionality.
>
> What if the underlying Xserver does not support "Xv" ?
Then implement the conversion/scaling in software, or don't expose it.
One thing I've been talking with Kieth about is possibly supporting YUV
surfaces in Render. I could see making them "special" so that YUV isn't
a valid target to render to (no hardware I know of implements it), and
the software implementation for reading would still be slow, but it
would be nice in that you could have a single xv implementation in your
DDX that just called to Render (hardware-accelerated on most drivers) to
do the drawing. And of course leave the old XV support around for
hardware that can't handle it.
(note that to do this well we do need more work to deal with vsync, but
that's needed anyway)
--
From mouschi at wi.rr.com Sun Jul 11 13:00:00 2004
From: mouschi at wi.rr.com (Ted Kaminski)
Date: Sun Jul 11 13:00:08 2004
In-Reply-To: <E1BjhX6-0007kS-29@evo.keithp.com>
References: <ye8u0we3hq1.fsf@ec03.daimi.au.dk>
<E1BjhX6-0007kS-29@evo.keithp.com>
Message-ID: <20040711150000.00007916@win01.wi.rr.com>
On Sun, 11 Jul 2004 09:50:32 -0700
Keith Packard <keithp@keithp.com> wrote:
> Around 13 o'clock on Jul 11, Soeren Sandmann wrote:
> > - mode setting
> >
> > Changing the mode of hardware
>
> We're already talking about moving this to an external library which can
> be shared by all graphics applications; my assumption here is that the
> system-dependent pieces for a 'Gl-solo' based X server would include an
> interface to this library.
>
> I don't have a solid idea about how that library should be constructed;
> whether the X server should be in charge of mode selection at any level or
> whether it should just react to externally controlled events.
I have another concern that sort of relates to this: games.
With a OpenGL-based X server, we're going to end up using a lot of video memory.
Games these days pretty much need all the resources they can get.
So, this relates to mode switching because of how I see this being solved. Curre
ntly, as a user, I see that linux will allow each VT to have its own mode. VT1 c
an be a 640x480 console, VT2 can be a 1600x1200 console, VT7 can be my 1024x768
X server. I assume that this is a result of framebuffer kernel support. I like t
his mechanism. To make a mode-changing library work with it, it'd need two metho
ds:
1. Create a new VT with a certain mode
2. Change the current VT's mode
Now, with method 1, the X server would start up and take a new VT, as it does no
w, but it also means that games would have an simple method of starting up and t
aking a new VT.
The reason that would be important is because of the (eventual?) video memory ma
nager that'd live in the kernel. That VMM could quite simply make all of video
memory be controled by whatever program controls the current VT. If the game nee
ds more video memory, the Xserver's is just displaced into system RAM by the ker
nel mechanism.
Obviously I'm concerned only with linux here, the mode changing library would ju
st need to be able to support this kind of behavior, not necessarily do it this
way (for other OSs without kernel support like this).
Does this make sense, or am I being naive? (I'm certainly not an X or kernel hac
ker...)
Ted
From jonsmirl at yahoo.com Sun Jul 11 13:31:13 2004
Date: Sun Jul 11 13:31:15 2004
--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Can opengl effectively extract 2D scroll/blit - that will matter for
> s/w mesa on 2D hardware ?
In Keith's composited model all apps are drawn to textures using
render_to_texture or something similar (pbuffers). In this model
glCopyTexSubImage2D is the same as the bitblt function.
There is also glCopyPixels which allows a rectangle of the display
buffer to be copied from one place to another in the display buffer.
These straight copies aren't as important in the composited model since
many things are alpha blended. You can't scroll something that is
translucent because of the bleed through.
I don't know if Keith's damage extensions are smart enough to scroll
opaque windows on a compositied desktop. The OpenGL functions for
scrolling are there, but X has to be smart enough to use them.
You can always continue to use XAA drivers on 2D hardware with the
current windowing system. It may be the case that there is no solution
for building a reasonably fast compositied system on existing 2D
hardware. This won't be OpenGL's fault, compositing relies heavily on
alphablended copies and the hardware may not support that.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Sun Jul 11 13:31:22 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don'tsupportit in
hardware...
<40F194CE.3ACF8370@nrubsig.org> <1089575211.891.112.camel@leguin>
Message-ID: <40F1A388.1F62B5C1@nrubsig.org>
Eric Anholt wrote:
> > > > Is there a way to implement the "Xv" extension on hardware which doesn't
> > > > support it (for example Xnest, Xvfb etc.) ?
> > >
> > > I guess since nobody can see the display in Xvfb a "correct"
> > > implementation would be to offer Xv overlays that have no-op functions
> > > (and anyone reading back the fb - well its a hardware overlay so you
> > > dont see the data ;))
> >
> > Dumb question:
> > I cannot implement "Xv" in a way like Mesa implements GLX for Xvfb (e.g.
> > push images via XPutImage()), right ?
> >
> > Are the "Xv" overlays _required_ to leave the underlying framebuffer
> > contents intact ?
>
> No, most XV implementations paint a color key on the underlying
> framebuffer,
Who paints the color key ? The server-side part of "Xv" ?
> so you typically don't read back the video if you do a
> screenshot, for example.
Known problem... :)
Would it be possible to implement a "generic" codepath in Xv which
renders the image using PutImage when there is no special support for Xv
in the DDX ?
> > > For Xnest there is certainly nothing preventing it providing you go off
> > > and write enough code. Xnest is an Xwindow, that means the Xv layer of
> > > the master X server is perfectly capable of handling an Xv subwindow in
> > > the Xnest window - you just have to get all the overlay offsets correct
> > > and propogate the functionality.
> >
> > What if the underlying Xserver does not support "Xv" ?
>
> Then implement the conversion/scaling in software, or don't expose it.
>
> One thing I've been talking with Kieth about is possibly supporting YUV
> surfaces in Render.
Uhm... we're doing some investigation whether it's possible to implement
non-RGB visuals using a "ColorSpace"-extension - having YUV- and
CYMK-visuals would be nice... :)
Maybe we should stick our heads together... is there any conference here
in europe you can visit this year ?
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 13:42:32 2004
hardware...
Message-ID: <40F1A622.D213361F@nrubsig.org>
Alan Cox wrote:
>
> On Sul, 2004-07-11 at 20:28, Roland Mainz wrote:
> > I cannot implement "Xv" in a way like Mesa implements GLX for Xvfb (e.g.
> > push images via XPutImage()), right ?
> > Are the "Xv" overlays _required_ to leave the underlying framebuffer
> > contents intact ?
>
> Given the 'virtual' frame buffer lacks hardware acceleration for any
> Xv functionality if you use null functions apps "work" so you can
> test/use them.
Depends... server-side image scaling is usually faster than client-side
(assuming you make the images larger :) because you transfer _less_
data. Much less...
> For any real app it would perform better anyway to
> use MITSHM
If - and only "if" - MITSHM is available and suitable for the
application. MITSHM itself is a PAIN on some OSes since the number and
size of the shared segments is _limited_. IMHO MITSHM should go away,
replaced by a shared memory X transport...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 15:46:13 2004
Subject: [Xorg] "long long" and "unsigned long long" in xc/ tree...
Message-ID: <40F1C32A.2B680B99@nrubsig.org>
Hi!
----
Are there _any_ platforms (for example: Debian/Linux on m68k) supported
by the Xorg tree which do NOT support "long long" and "unsigned long
long" (=64bit integer variables) ? I'd like to add some code which uses
|long long| _everywhere_ and cannot be easily modified to work without
it...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Sun Jul 11 15:46:36 2004
In-Reply-To: <1089571106.23027.14.camel@stargrazer.home.awesomeplay.com>
On Sun, 11 Jul 2004, Sean Middleditch wrote:
> On Sun, 2004-07-11 at 20:51 +0300, Ely Levy wrote:
> >
> > On Sun, 11 Jul 2004, Sean Middleditch wrote:
>
> > > Fourth, a vast array of applications use custom widgets. How would
> > > those work? You'd either need to still allow client-side drawing (and
> > > then all the client-side support to mimic the themes and styles of the
> > > server-side widgets) or let clients upload code/scripts to the (again)
> > > root-running server.
> >
> > Backward compatibilty is always a problem,
> > You won't get anywhere without breaking it from time to time,
> > Both solutions you offered seemed to work though, still allowing
> > client-side drawing would work for a while. and as I said before
> > the fact xserver runs as root needs to be fixed anyhow.
> > (I think it's not like that on some other systems?)
>
> You're msising the point. It has nothing to do with backwards
> compatibility. It has to do with applications needing custom widgets.
> You will never come up with a list of widgets that covers everything
> every application needs. In order to support any new or custom widgets
> apps may need down the road, you need client-side drawing, and all the
> complex machinery and API for client-side theming and such. What point
> then is there in the server?
Well, then having extandble widget set is the answer,
most applications uses widgets from a tool kit like motif gnome kde and
the like anyhow, and those who doesn't can either use client side widgets
or upload their widget to the server.
The exact way should probebly be thought of to find an efficient solution
but it doesn't sound impossible.
Ofcourse if someone is going to implemant it you need to find a good
flexible way to make programer life easier.
something like XUL or c# or that weird ps language someone mentioned
before:)
> > > Fifth, how do you advance the state of the art? We started off with
> > > things like Xt, Motif, etc. GTK+/Qt are much better than those in so
> > > many ways. They probably couldn't have developed so quickly and with so
> > > much innovation if they were limited to using a pre-defined protocol for
> > > server-side widgets, and had to run in the display server.
> >
> > True,
> > But maybe we got to the point where things are more stable?
> > I know fd.o is making a lot of effords making GTK/Qt (gnome/kde)
> > agree on certain standards, that can be yet another one.
> > other option like you said is to make it in extandable way
> > following the long X tradition:)
> > (uploading bytecode to the server?)
>
> The standards have very little to do with how the widgets look or act.
> That is entirely something that should never be standardized, because
> there is a big reason they act differently in those respects.
Why not? most widgets look the same, and good scripting method can solve
the flexibility problem without hurting the uniformaty of the desktop.
> ALso, what about any new ideas down the road? Something like Looking
> Glass, maybe. Putting things in the server shoots future innovation in
> the foot.
Again, I'm not saying throwing away client side, I'm sure there would be
programs who would want to use it, I'm not saying closing the door to
other sorts of extentions or making people use it.
But I think that the it can be mainstream.
That's the beauty of opensource, applications support standards
but if they want they can add their own unstandard methods.
> >
> > > Sixth, who has _proven_ they're actually faster in the server?
> > > Especially for more complex widgets? Imagine something like the tree
> > > view in GTK+ - the server would need access to all that information so
> > > that if the user scrolls around, it knows what to display. No way that
> > > could be faster in the server.
> >
> > I think both ywindows and fresco debated about that,
> > I guess what pushed it is less the speed which would probebly won't
> > make that much diffrent, but the fact it's uniform and easier to use.
>
> How? Either way, apps just call an API. The application in no way
> should care whether the widgets in that API are implemented in the
> client-side library or server. Unless they start doing custom widgets
> (quite common), in which case the client-side API is much easier.
I don't see why it would be easier if you have good language for server
side..
> And the speed _would_ be a huge factor. The server woudl either need
> all the information that client has about the client-specific data, or
> there would need to be a metric ton of signals/messages going back-and-
> forth to keep things updated (i.e., messages requiring round-trips and
> thus latency, which just having the client redraw the widget view
> wouldn't need to anywhere near the same degree). Either way, you are
> going to run no faster, possibly a lot slower, than what we have now...
ok, there are other servers using a similar method,
we can go and check how they did it and see if it's indeed slower.
Someone mentioned DPS saying Xsun uses it.
Can someone who knows it elebrate on how they solved those problems?
> so why bother? If the only advantages anybody has ever tried to list
> for putting widgets server-side isn't true, then putting them server-
> side is a pretty goofy thing to do.
>
Ofcourse, but I'm preety sure that it is.
in my pervious mail I email a link to someone thesis about the subject,
and fresco guys seems very supportive of it.
I wouldn't be so fast rolling it out.
Ely
Date: Sun Jul 11 15:58:26 2004
Message-ID: <40F1C5F8.90DD5167@nrubsig.org>
Ely Levy wrote:
[snip]
> Well, then having extandble widget set is the answer,
> most applications uses widgets from a tool kit like motif gnome kde and
> the like anyhow, and those who doesn't can either use client side widgets
> or upload their widget to the server.
> The exact way should probebly be thought of to find an efficient solution
> but it doesn't sound impossible.
> Ofcourse if someone is going to implemant it you need to find a good
> flexible way to make programer life easier.
> something like XUL or c# or that weird ps language someone mentioned
> before:)
Using XUL is a BAD idea. We would have to import half of Mozilla's
codebase into the X.org tree just to get that working. Hint: The Mozilla
code base is AFAIK larger than the whole X.org tree. It sounds like
hunting chicken with a Leopard-II tank...
[snip]
> > And the speed _would_ be a huge factor. The server woudl either need
> > all the information that client has about the client-specific data, or
> > there would need to be a metric ton of signals/messages going back-and-
> > forth to keep things updated (i.e., messages requiring round-trips and
> > thus latency, which just having the client redraw the widget view
> > wouldn't need to anywhere near the same degree). Either way, you are
> > going to run no faster, possibly a lot slower, than what we have now...
>
> ok, there are other servers using a similar method,
> we can go and check how they did it and see if it's indeed slower.
> Someone mentioned DPS saying Xsun uses it.
> Can someone who knows it elebrate on how they solved those problems?
Alan may know the details...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From sand at blarg.net Sun Jul 11 16:08:22 2004
Date: Sun Jul 11 16:08:18 2004
In-Reply-To: <E1Bic7z-0001kx-D7@evo.keithp.com>
<E1Bic7z-0001kx-D7@evo.keithp.com>
> You don't get to change X.h at all; you can't add new event masks to the
> protocol (the X server would have to be changed to support them), and you
> needn't add new Button? names. I'd add Xt specific button names instead
>
> #define XtButton6 6
> #define XtButton7 7
>
> I don't know how hard it will be to get Xt to accept buttons for which no
> event selection or state bits exist, but that's the only way to make this
> work.
Here's a revised patch that only touches libXt-0.1.5. Because the X11
protocol doesn't have event masks for those buttons, we can't use the
buttons in drag events. What we *can* do is bind actions to up and
down events on them. For example:
xterm.vt100.translations: #override\n\
<Btn6Up>:insert-selection(CLIPBOARD) \n\
<Btn7Up>:select-set(CLIPBOARD) \n\
<Btn6Down>:ignore() \n\
<Btn7Down>:ignore() \n\
<BtnUp>:ignore() \n
Derek
--
Derek Upham
sand@blarg.net
------------------------------ cut here ------------------------------
diff -u -r libXt-0.1.5.orig/TMparse.c libXt-0.1.5/TMparse.c
--- libXt-0.1.5.orig/TMparse.c 2003-05-27 15:26:43.000000000 -0700
+++ libXt-0.1.5/TMparse.c 2004-07-11 14:57:32.000000000 -0700
@@ -88,6 +88,15 @@
#define MIN(a,b) (((a) < (b)) ? (a) : (b))
#endif

+/* The core X11R6 protocol predates 7-button mice.
+ * This prevents us from referring to those buttons in event masks.
+ * We *can* recognize basic up/down events for those buttons, since
+ * those use the plain button number. Compare with the "Button5"
+ * pre-processor definition in "X.h".
+ */
+#define XtButton6 6
+#define XtButton7 7
+
static String XtNtranslationParseError = "translationParseError";

typedef int EventType;
@@ -160,6 +169,8 @@
+ {"Button6", 0, XtButton6},
+ {"Button7", 0, XtButton7},
{NULL, NULLQUARK, 0},
};

@@ -245,6 +256,8 @@
+{"Btn6Down", NULLQUARK, ButtonPress, ParseImmed,(Opaque)XtButton6},
+{"Btn7Down", NULLQUARK, ButtonPress, ParseImmed,(Opaque)XtButton7},

/* Event Name, Quark, Event Type, Detail Parser, Closure */

@@ -255,6 +268,8 @@
+{"Btn6Up", NULLQUARK, ButtonRelease, ParseImmed,(Opaque)XtButton6},
+{"Btn7Up", NULLQUARK, ButtonRelease, ParseImmed,(Opaque)XtButton7},

{"MotionNotify", NULLQUARK, MotionNotify, ParseTable, (Opaque)motionDetails}
,
{"PtrMoved", NULLQUARK, MotionNotify, ParseTable, (Opaque)motionDetails},
Date: Sun Jul 11 16:14:35 2004
On Mon, 2004-07-12 at 01:46 +0300, Ely Levy wrote:
> On Sun, 11 Jul 2004, Sean Middleditch wrote:
> >
> > The standards have very little to do with how the widgets look or act.
> > That is entirely something that should never be standardized, because
> > there is a big reason they act differently in those respects.
>
> Why not? most widgets look the same, and good scripting method can solve
> the flexibility problem without hurting the uniformaty of the desktop.
Why bother inventing a whole new scripting/widget system for no proven
gain? Why don't we solve real problems instead of making them up just
to look for solutions...?
> >
> > How? Either way, apps just call an API. The application in no way
> > should care whether the widgets in that API are implemented in the
> > client-side library or server. Unless they start doing custom widgets
> > (quite common), in which case the client-side API is much easier.
>
> I don't see why it would be easier if you have good language for server
> side..
Because the language has nothing to do with it. It's a basic problem of
"who has the data?" If the server is responsible for arranging and
displaying the data, but the client has the data, then the server needs
access to that data. Which means the client code now has to store the
data in some special format that's dependent on the display system being
used (which also then makes making cross-platform clients a pain in the
arse), or the data has to be copied to the server. Either solution is
stupid.
And the server shouldn't have a language. Why do we need to make
everything so complex? What we have _works_, and works absolutely fine.
We have no shortage of speed, no shortage of flexibility, no shortage of
features... there is _no_ reason to make things more complex and
introduce all sorts of new APIs and such for developers to learn for no
good actual reason. "If it ain't broke, don't fix it." ;-)
>
> > And the speed _would_ be a huge factor. The server woudl either need
> > all the information that client has about the client-specific data, or
> > there would need to be a metric ton of signals/messages going back-and-
> > forth to keep things updated (i.e., messages requiring round-trips and
> > thus latency, which just having the client redraw the widget view
> > wouldn't need to anywhere near the same degree). Either way, you are
> > going to run no faster, possibly a lot slower, than what we have now...
>
> ok, there are other servers using a similar method,
> we can go and check how they did it and see if it's indeed slower.
Display PostScript is, iirc, not a widget system. It's a 2D rendering
system. I.e., what we already have with X/GLX/RENDER. The client
doesn't do the actual rendering, it just sends some high-level commands
to the server (like draw trapezoid with properties foo and bar) and the
server does all the rendering.
That's why widgets on the server don't really offer even much
theoretical speed gain; today's clients already have very little
traffic. Putting widgets in the server would mostly just change what
traffic that is. (Instead of low-level input events and high-level
drawing commands, it'd be requests for information and high-level input
events.)
>
> > so why bother? If the only advantages anybody has ever tried to list
> > for putting widgets server-side isn't true, then putting them server-
> > side is a pretty goofy thing to do.
> >
>
> Ofcourse, but I'm preety sure that it is.
Prove it. ;-)
> in my pervious mail I email a link to someone thesis about the subject,
> and fresco guys seems very supportive of it.
Fresco guys haven't made anything usable other than some basic tech
demos. The in-development extensions for kdrive/Xorg can let Xorg do
everything Fresco can without needing overly complex server-side trash.
Honestly, in the end, any such design probably isn't going to be X,
it'll be something new (like Fresco), so this is probably entirely the
wrong list to be discussing it...
> I wouldn't be so fast rolling it out.
>
> Ely
>
>
From idr at us.ibm.com Sun Jul 11 16:46:33 2004
Date: Sun Jul 11 16:47:13 2004
In-Reply-To: <20040711150000.00007916@win01.wi.rr.com>
References: <ye8u0we3hq1.fsf@ec03.daimi.au.dk> <E1BjhX6-0007kS-29@evo.keithp.co
m>
<20040711150000.00007916@win01.wi.rr.com>
Message-ID: <40F1D159.70707@us.ibm.com>
Ted Kaminski wrote:
> I have another concern that sort of relates to this: games.
>
> With a OpenGL-based X server, we're going to end up using a lot of video memor
y. Games these days pretty much need all the resources they can get.
Actually, we'll probably use *less*. With the open-source drivers, if
you have a display that's 1600x1200, the back and depth buffers are
statically allocated to be that size. If you run the game at 1024x768,
there's a huge chunk of memory that's unused. If you treat every window
like a pbuffer (or some similar abstration), you can kick them out of
video memory (the same way the kernel kicks applications out of physical
memory). You have to make sure that there are no rendering commands
queued by the graphics engine to render to that surface, but it's still
completely doable.
Date: Sun Jul 11 18:44:00 2004
> Ely Levy wrote:
> [snip]
> > Well, then having extandble widget set is the answer,
> > most applications uses widgets from a tool kit like motif gnome kde and
> > the like anyhow, and those who doesn't can either use client side widgets
> > or upload their widget to the server.
> > The exact way should probebly be thought of to find an efficient solution
> > but it doesn't sound impossible.
> > Ofcourse if someone is going to implemant it you need to find a good
> > flexible way to make programer life easier.
> > something like XUL or c# or that weird ps language someone mentioned
> > before:)
>
> Using XUL is a BAD idea. We would have to import half of Mozilla's
> codebase into the X.org tree just to get that working. Hint: The Mozilla
> code base is AFAIK larger than the whole X.org tree. It sounds like
> hunting chicken with a Leopard-II tank...
>
I'm not sure about that,
There might be a way to do it without using too much of mozilla code.
or even doing our own renderer.
I heard about a mozilla project which suppose to be a XUL based
replacement to XAML, which might be intresting for this discussion.
but again I was just brining up ideas, if someone knows a better langauge
I'll be happy to hear:)
Ely
Date: Sun Jul 11 19:07:21 2004
Message-ID: <40F1F24C.3A227827@nrubsig.org>
Ely Levy wrote:
[snip]
> > Using XUL is a BAD idea. We would have to import half of Mozilla's
> > codebase into the X.org tree just to get that working. Hint: The Mozilla
> > code base is AFAIK larger than the whole X.org tree. It sounds like
> > hunting chicken with a Leopard-II tank...
> >
> I'm not sure about that,
> There might be a way to do it without using too much of mozilla code.
> or even doing our own renderer.
> I heard about a mozilla project which suppose to be a XUL based
> replacement to XAML, which might be intresting for this discussion.
> but again I was just brining up ideas, if someone knows a better langauge
> I'll be happy to hear:)
It's not "just the language". Using XUL will end-up in a pain:
You need code to render XUL, which requires a very complex layout
engine. Then you need CSS for some stuff, making layout even more
complex (just think about tables). Then you need to render _text_...
which itself results in the requirent for scalers, shapers etc (sure,
you can plug-in ICU here :)
Finally you get a monster which depends on glib, Pango, ICU and most of
the other Gnome libraries. I am not sure whether all this stuff belongs
into the Xserver, especially into a Xserver which permanently runs as
user "root".
And that's only the tip of the iceberg.
Above describes the problems with layout, rendering and some of the
dependicies. How do you connect the widgets to each other within the
server side ? Well... XUL mainly uses JavaScript for that... which means
we would need a javascript engine, preferably a preemptive one... and I
am not sure whether everyone here wants JS as primary server-side widget
language.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From Alan.Coopersmith at Sun.COM Mon Jul 12 00:49:17 2004
Date: Mon Jul 12 00:49:49 2004
In-Reply-To: <40F1878E.1374DA5@nrubsig.org>
<40F1878E.1374DA5@nrubsig.org>
Message-ID: <40F2427D.50403@Sun.COM>
Roland Mainz wrote:
> What about allowing JAVA applications run within the Xserver ?
I think the Looking Glass team looked into this, but decided against
it due to the work needed to either make the entire X server MT-safe
or to make the JVM non-threaded. It's not impossible, just a lot of
work, for not a lot of obvious immediate benefit over just using a
client side JVM.
--
Date: Mon Jul 12 00:53:50 2004
side widgets
In-Reply-To: <40F179BF.A788B321@nrubsig.org>
<40F179BF.A788B321@nrubsig.org>
Message-ID: <40F24370.1090007@Sun.COM>
Roland Mainz wrote:
> [snip]
>
>>Third, speaking of root, do you really want all that complex code in
>>such a process? The more code you have, the more potential bugs and
>>security holes.
>
>
> This is _ONLY_ a problem of the Linux Xserver. Solaris and other Unices
> run their Xserver under plain user accounts.
Solaris x86 Xsun runs as root - only on SPARC does Solaris Xsun not
require uid root priveledges. On x86, it requires root to get access
to the PCI bus & card registers and memory mappings. (On SPARC, it's
setgid root in order to do process priority adjustments and power
control of the display & frame buffer.)
> or turning
> the drivers into kernel modules (AFAIK Solaris Xsun does it that way).
Yes, on SPARC. On x86, it doesn't since it would take much longer to
get devices ported, and keep us from using the Xorg/XFree86 open source
drivers without a lot of extra effort.
--
Date: Mon Jul 12 00:56:24 2004
Message-ID: <40F243EC.5020004@Sun.COM>
Ely Levy wrote:
> Backward compatibilty is always a problem,
> You won't get anywhere without breaking it from time to time,
X has gotten a long ways without breaking backward compatibility in
almost two decades. That's a lot of legacy software that needs to
be supported for anyone to be able to use anything new.
--
Date: Mon Jul 12 01:01:19 2004
Ely Levy wrote:
DPS is simply a server-side Postscript rendering engine - not server
side widgets. (Perhaps someone is confusing DPS with NeWS, which was
a completely separate window system that used Postscript rendering and
server side widgets. You should be able to find out more about that
in a web search of long-ago window system wars.)
About the only thing that DPS actually is used for in Xsun today is
viewing Postscript documents in the CDE & OpenWindows image viewers.
(GNOME on Solaris uses Ghostscript on the client side to display
Postscript files, just like GNOME on Linux.)
--
Date: Mon Jul 12 01:22:41 2004
On Sun, Jul 11, 2004 at 04:16:59PM +0300, Ely Levy wrote:
> And what about the move to XCB?
> By their page I uderstand they are preety much done,
> is there a general time table? or what need to be done?
XCL is incomplete, and the X server doesn't need to change; the libs
just need to be added.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040712/c74a00e3/attach
ment.pgp
From michel at daenzer.net Mon Jul 12 01:40:43 2004
Date: Mon Jul 12 01:43:18 2004
<1089411710.14845.20.camel@localhost>
On Sat, 2004-07-10 at 00:21 +0200, Michel D?nzer wrote:
> On Fri, 2004-07-09 at 13:54 -0400, Kevin E Martin wrote:
> >
>
> The DRI code in the X.Org tree is broken in some respects on big endian
> machines. I've fixed texturing in Mesa CVS, but there are probably still
> issues with the new t_vertex code, which only affect software TCL
> though, i.e. mostly Radeon 7000 and M6.
OTOH, I'm not sure that the radeon DRI driver has even been converted to
use t_vertex yet... also keep in mind that drivers that haven't and that
don't support TCL in hardware were broken by other Mesa changes a while
ago, e.g. bzflag will look like
http://penguinppc.org/~daenzer/DRI/resolved/bzflag.jpeg . See e.g.
http://freedesktop.org/bugzilla/show_bug.cgi?id=716 .
--
Date: Mon Jul 12 02:07:04 2004
Subject: [Xorg] OT: radeon questions
Greetings;
A patch for the kernels radeonfb just went by on lkml, and I've
applied it and am rebuilding 2.6.8-rc1.
I just ran lsmod and found that allthough I have it made as a module,
it wasn't loaded, and neither is anything that looks like dri.
I've added a 'modprobe radeonfb' to my rc.local but haven't yet
rebooted. modprobing it while x is running (XFree86-4.3.2) resulted
in severe screen damages that required several screen switches to
fully recover, and it seems (subjectively) to be slower. glxgears is
apparently not using it under these conditions, still in the 170-200
fps area. Thats essentiually a 'no change'.
Currently that portion of the lsmod output looks like this:
[root@coyote drivers]# lsmod
Module Size Used by
radeonfb 56936 0
cfbcopyarea 3904 1 radeonfb
cfbimgblt 3008 1 radeonfb
cfbfillrect 3712 1 radeonfb
So its loaded but apparently not being used.
Where is the really proper place to put the loading commands (and the
synatx to do it) so I get it all, well before X is started by hand
after I login at runlevel 3?
--
Cheers, Gene
From michel at daenzer.net Mon Jul 12 02:20:43 2004
Date: Mon Jul 12 02:24:01 2004
On Mon, 2004-07-12 at 05:06 -0400, Gene Heskett wrote:
>
> I've added a 'modprobe radeonfb' to my rc.local but haven't yet
> rebooted. modprobing it while x is running (XFree86-4.3.2) resulted
> in severe screen damages that required several screen switches to
> fully recover,
Sure, that's a bad idea. You're lucky nothing worse happened.
> and it seems (subjectively) to be slower.
Must really be subjective, it shouldn't make any difference.
> glxgears is apparently not using it under these conditions, still in the
> 170-200 fps area. Thats essentiually a 'no change'.
radeonfb isn't related to the DRI at all. You're probably looking for
the radeon DRM, the kernel module is called just 'radeon'.
> Currently that portion of the lsmod output looks like this:
>
> [root@coyote drivers]# lsmod
> Module Size Used by
> radeonfb 56936 0
> cfbcopyarea 3904 1 radeonfb
> cfbimgblt 3008 1 radeonfb
> cfbfillrect 3712 1 radeonfb
>
> So its loaded but apparently not being used.
You'd have to map consoles to it or start the X server with Option
"UseFBDev" to change that. But it sounds like you don't really need
either.
--
Date: Mon Jul 12 02:52:23 2004
On Monday 12 July 2004 05:06, Gene Heskett wrote:
>Greetings;
>
>A patch for the kernels radeonfb just went by on lkml, and I've
>applied it and am rebuilding 2.6.8-rc1.
>
>I just ran lsmod and found that allthough I have it made as a
> module, it wasn't loaded, and neither is anything that looks like
> dri.
>
>I've added a 'modprobe radeonfb' to my rc.local but haven't yet
>rebooted. modprobing it while x is running (XFree86-4.3.2) resulted
>in severe screen damages that required several screen switches to
>fully recover, and it seems (subjectively) to be slower. glxgears
> is apparently not using it under these conditions, still in the
> 170-200 fps area. Thats essentiually a 'no change'.
>
>Currently that portion of the lsmod output looks like this:
>
>[root@coyote drivers]# lsmod
>Module Size Used by
>radeonfb 56936 0
>cfbcopyarea 3904 1 radeonfb
>cfbimgblt 3008 1 radeonfb
>cfbfillrect 3712 1 radeonfb
>
>So its loaded but apparently not being used.
>
>Where is the really proper place to put the loading commands (and
> the synatx to do it) so I get it all, well before X is started by
> hand after I login at runlevel 3?
Followup, loading radeonfb in rc.local resulted in a blank screen on
reboot as soon as it was loaded, as in no characters were displayed
although the cursor was visible and in the correct location. I had
to login blind, and do the startx blind. X worked just fine, but
didn't use the radeonfb that was loaded. After exiting X, I tried
to rmmod radeonfb (typing blind) which apparently worked as the
screen went totally black, not even a cursor, but I was able to type
reboot and do so. After the reboot I added a 'Load "radeonfb"' to
the XF86Config file, but that was rejected by X as it couldn't find
the module according to the logfile.
So how does one make use of this radeonfb kernel module? Do I need to
build it into the kernel? The kernels Documentation dir, and the
drivers/video/aty dirs are both bareft of any mention of this, as is
the .config help.
--
Cheers, Gene
From loc at toya.net.pl Mon Jul 12 02:52:57 2004
Date: Mon Jul 12 02:53:05 2004
Subject: [Xorg] [debrix] trident driver
In-Reply-To: <200407102218.20426.qbast@go2.pl>
References: <200407102218.20426.qbast@go2.pl>
Message-ID: <40F25F79.4030407@toya.net.pl>
Jakub Stachowski wrote:
> Hello,
>
> I finished autotooling trident driver for debrix. First patch is against
> debrix-driver-trident from xserver cvs. It is based on autotooled ati driver.
>
> Second patch is for debrix/hw/xorg/loader/xf86sym.c from Daniel Stone's arch
> repository with patch from Jakub Piotr C?apa (posted earlier). It adds some
> symbols referenced by the driver.
> Tested on Toshiba laptop with CyberBlade/XP - everything works without
> problems.
Any feedback? Daniel, if you commited this *please* leave a note on the
list. ``Commited'' should be sufficient.
Same thing applies to ``my'' (I've just did what the other Jakub told me
;) patch for the loader and my libXp autotoolization.
--
Regards,
Jakub Piotr C?apa
Date: Mon Jul 12 03:01:58 2004
In-Reply-To: <1089625605.25298.0.camel@dogfish.marketpipe.com>
<1089625605.25298.0.camel@dogfish.marketpipe.com>
On Monday 12 July 2004 05:46, Torgeir Veimo wrote:
>On Mon, 2004-07-12 at 05:06 -0400, Gene Heskett wrote:
>> Greetings;
>>
>> A patch for the kernels radeonfb just went by on lkml, and I've
>> applied it and am rebuilding 2.6.8-rc1.
>
>Do you have an exact link? I don't monitor that ml. Does it still
> use macmodes.h?
Here it is:
From eger@havoc.gtf.org Mon Jul 12 02:22:36 2004
[...]
From: David Eger <eger@havoc.gtf.org>
To: akpm@osdl.org
Cc: benh@kernel.crashing.org,
linux-kernel@vger.kernel.org
Subject: [PATCH] radeonfb: cleanup and little fixes
[...]
Dear Andrew, Please apply.
radeonfb: cleanup and little fixes
Very similar to Fran??ois Romieu's fixes for cirrusfb, here we:
* Provide meaningful error values from radeonfb_pci_register()
* Fix unbalanced pci_enable_device()
* Fix unbalanced fb_alloc_cmap()
* Fix a failure-case bug where we accidentally memset_io(0, 0, size);
* Use pci_request_regions() instead of request_mem_region()
Signed-off-by: David Eger <eger@havoc.gtf.org>
diff -Nru a/drivers/video/aty/radeon_base.c
b/drivers/video/aty/radeon_base.c
--- a/drivers/video/aty/radeon_base.c 2004-07-12 07:58:26 +02:00
+++ b/drivers/video/aty/radeon_base.c 2004-07-12 07:58:26 +02:00
@@ -2069,19 +2069,22 @@
struct fb_info *info;
struct radeonfb_info *rinfo;
u32 tmp;
+ int ret;

RTRACE("radeonfb_pci_register BEGIN\n");

/* Enable device in PCI config */
- if (pci_enable_device(pdev) != 0) {
+ ret = pci_enable_device(pdev);
+ if (ret < 0) {
printk(KERN_ERR "radeonfb: Cannot enable PCI device\n");
- return -ENODEV;
+ goto err_out;
}

info = framebuffer_alloc(sizeof(struct radeonfb_info), &pdev->dev);
if (!info) {
printk (KERN_ERR "radeonfb: could not allocate memory\n");
- return -ENODEV;
+ ret = -ENOMEM;
+ goto err_disable;
}
rinfo = info->par;
rinfo->info = info;
@@ -2106,23 +2109,19 @@
rinfo->mmio_base_phys = pci_resource_start (pdev, 2);

/* request the mem regions */
- if (!request_mem_region (rinfo->fb_base_phys,
- pci_resource_len(pdev, 0), "radeonfb")) {
- printk (KERN_ERR "radeonfb: cannot reserve FB region\n");
- goto free_rinfo;
- }
-
- if (!request_mem_region (rinfo->mmio_base_phys,
- pci_resource_len(pdev, 2), "radeonfb")) {
- printk (KERN_ERR "radeonfb: cannot reserve MMIO region\n");
- goto release_fb;
+ ret = pci_request_regions(pdev, "radeonfb");
+ if (ret < 0) {
+ printk( KERN_ERR "radeonfb: cannot reserve PCI regions."
+ " Someone already got them?\n");
+ goto err_release_fb;
}

/* map the regions */
- rinfo->mmio_base = (unsigned long) ioremap (rinfo->mmio_base_phys,
RADEON_REGSIZE);
+ rinfo->mmio_base = (unsigned long) ioremap(rinfo->mmio_base_phys,
RADEON_REGSIZE);
if (!rinfo->mmio_base) {
- printk (KERN_ERR "radeonfb: cannot map MMIO\n");
- goto release_mmio;
+ printk(KERN_ERR "radeonfb: cannot map MMIO\n");
+ ret = -EIO;
+ goto err_release_pci;
}

/* On PPC, the firmware sets up a memory mapping that tends
@@ -2226,23 +2225,20 @@

RTRACE("radeonfb: probed %s %ldk videoram\n", (rinfo->ram_type),
(rinfo->video_ram/1024));

- rinfo->mapped_vram = MAX_MAPPED_VRAM;
- if (rinfo->video_ram < rinfo->mapped_vram)
- rinfo->mapped_vram = rinfo->video_ram;
- for (;;) {
+ rinfo->mapped_vram = min_t(unsigned long, MAX_MAPPED_VRAM,
rinfo->video_ram);
+
+ do {
rinfo->fb_base = (unsigned long) ioremap (rinfo->fb_base_phys,
rinfo->mapped_vram);
- if (rinfo->fb_base == 0 && rinfo->mapped_vram > MIN_MAPPED_VRAM)
{
- rinfo->mapped_vram /= 2;
- continue;
- }
- memset_io(rinfo->fb_base, 0, rinfo->mapped_vram);
- break;
- }
+ } while ( rinfo->fb_base == 0 &&
+ ((rinfo->mapped_vram /=2) >= MIN_MAPPED_VRAM) );

- if (!rinfo->fb_base) {
+ if (rinfo->fb_base)
+ memset_io(rinfo->fb_base, 0, rinfo->mapped_vram);
+ else {
printk (KERN_ERR "radeonfb: cannot map FB\n");
- goto unmap_rom;
+ ret = -EIO;
+ goto err_unmap_rom;
}

RTRACE("radeonfb: mapped %ldk videoram\n", rinfo->mapped_vram/1024);
@@ -2329,10 +2325,11 @@
radeon_pm_enable_dynamic_mode(rinfo);
printk("radeonfb: Power Management enabled for Mobility
chipsets\n");
}
-
- if (register_framebuffer(info) < 0) {
+
+ ret = register_framebuffer(info);
+ if (ret < 0) {
printk (KERN_ERR "radeonfb: could not register framebuffer\n");
- goto unmap_fb;
+ goto err_unmap_fb;
}

#ifdef CONFIG_MTRR
@@ -2358,30 +2355,30 @@
RTRACE("radeonfb_pci_register END\n");

return 0;
-unmap_fb:
+err_unmap_fb:
iounmap ((void*)rinfo->fb_base);
-unmap_rom:
+err_unmap_rom:
if (rinfo->mon1_EDID)
kfree(rinfo->mon1_EDID);
if (rinfo->mon1_modedb)
fb_destroy_modedb(rinfo->mon1_modedb);
+ fb_dealloc_cmap(&info->cmap);
#ifdef CONFIG_FB_RADEON_I2C
radeon_delete_i2c_busses(rinfo);
#endif
if (rinfo->bios_seg)
radeon_unmap_ROM(rinfo, pdev);
iounmap ((void*)rinfo->mmio_base);
-release_mmio:
- release_mem_region (rinfo->mmio_base_phys,
- pci_resource_len(pdev, 2));
-release_fb:
- release_mem_region (rinfo->fb_base_phys,
-free_rinfo:
+err_release_pci:
+ pci_release_regions(pdev);
+err_release_fb:
framebuffer_release(info);
- return -ENODEV;
+err_disable:
+ pci_disable_device(pdev);
+err_out:
+ return ret;
}

@@ -2413,10 +2410,7 @@
iounmap ((void*)rinfo->mmio_base);
iounmap ((void*)rinfo->fb_base);

- release_mem_region (rinfo->mmio_base_phys,
- release_mem_region (rinfo->fb_base_phys,
+ pci_release_regions(pdev);

@@ -2427,7 +2421,9 @@
#ifdef CONFIG_FB_RADEON_I2C
radeon_delete_i2c_busses(rinfo);
#endif
+ fb_dealloc_cmap(&info->cmap);
framebuffer_release(info);
+ pci_disable_device(pdev);
}

-
It compiled ok here & I'm running that kernel now, but its not showing
a link count if I load it.
--
Cheers, Gene
From torgeir at pobox.com Mon Jul 12 03:04:20 2004
From: torgeir at pobox.com (Torgeir Veimo)
Date: Mon Jul 12 03:04:25 2004
Message-ID: <1089626660.25298.6.camel@dogfish.marketpipe.com>
On Mon, 2004-07-12 at 05:52 -0400, Gene Heskett wrote:
> So how does one make use of this radeonfb kernel module? Do I need to
> build it into the kernel? The kernels Documentation dir, and the
> drivers/video/aty dirs are both bareft of any mention of this, as is
> the .config help.
Building it into the kernel helps. Also, specify VGA_CONSOLE=N in .
config.
--
Torgeir Veimo <torgeir@pobox.com>
Date: Mon Jul 12 04:52:05 2004
In-Reply-To: keithp@keithp.com wrote on Wednesday,
7 July 2004 at 08:43:37 -0700
<E1BiEa9-00075k-Eg@evo.keithp.com>
>
>
> > For HW access this is certainly true, but it also deosn't make the kernel
> > a better choice than user land.
>
> Yes, that's exactly right. We need to treat any such code with the same
> care one would treat the kernel itself, it's all essentially equivalent.
>
> > On the other hand a sloppy written user land code will probably just
> > segfault while similar flaws in a kernel module may mess up your entire
> > system.
>
> The contrarary is equally true; kernel mistakes often result in benign
> (from the system perspective) oopses while user-level mistakes can easily
> lock up the PCI bus. Touching device registers is like that; there's no
> magic bullet here.
We are talking about different things here. If code in user land locks up
the bus the same code in the kernle will certainly have the same effect.
It certainly will not just produce a 'benign oops'.
Egbert.
Date: Mon Jul 12 04:53:23 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Wednesday,
7 July 2004 at 08:45:09 -0700
Jon Smirl writes:
>
> While trying to fix the radeonfb driver, BenH has run into some laptops
> that take the system BIOS and VBIOS, put them into a single image,
> compress it, and put it into a ROM. They can do this because the video
> is build into the motherboard. I don't know how you are going to find
> this without help from the system or using the C000:0 copy.
>
With some tricks (possibly by using the BIOS system vectors) you can
often locate pages where the BIOS lives. Of course you can only use
the pre-POSTED copy which lives somehwere beween 0xc0000 and 0xfffff.
On these systems I have found that it is unwise to re-POST anyway
as this may lead to undesireable results. In the best case the video
BIOS tries to call into some vendor specific call in the system BIOS.
Egbert.
Date: Mon Jul 12 05:24:18 2004
In-Reply-To: ajax@nwnk.net wrote on Wednesday, 7 July 2004 at 13:12:05 -0400
<200407061240.41575.ajax@nwnk.net>
<16619.55940.456062.637560@xf11.fra.suse.de>
<200407071312.06968.ajax@nwnk.net>
> Hash: SHA1
>
> On Wednesday 07 July 2004 07:12, Egbert Eich wrote:
> > Adam Jackson writes:
> > > I would posit, however, that OS-independence in drivers is a false
> > > economy. OSes are cheap, get a multi-boot rig and compile them all
> > > directly. Or use a cross-compiler. From the perspective of the
> > > graphics card manufacturer, you'd need to have the target platform
> > > around for testing anyway if you're going to declare it a supported
> > > platform.
> >
> > Well, do we believe the average developer will set up multiple
> > OSes or set up cross compile environments to provide binaries
> > for all supported OSes?
>
> Who's your average developer? If it's an OSS dev, then binary compatibility
> (almost always a hack) isn't relevant, because the user has source
> compatibility, and they can build their own native modules. If your average
> developer is a distribution release engineer, then they already have either
> native or cross-compilation facilities for all their supported platforms.
Most users I know are not able to build their own native modules.
They have to rely on somebody to prebuild the modules for them.
A lot of these users will be happy to install a prebuild binary
module I email them when I provide the command line that copies
it to the right place.
>
> I'd also point out that sourceforge (for example) has devel machines for many

> of the common platforms, and that fd.o could easily set up cross-compilers...
This is not an elegant solution either.
>
> The only people who might suffer - maybe - would be graphics companies
> releasing closed drivers. But let's dissect that assumption. All the
> MetroLink loader really buys you, over the libdl loader, is module
> portability between platforms with different executable formats. No, really.

> The libc wrapper (which I'm not really opposed to) already insulates you from

> the system libc. You've already assumed a processor. The only free variable

> left is whether you can open the module using the system libdl.
>
> Which leads me to...
I agree that today you get pretty far by assuming that systems are capable
of loading ELF binary modules. Therefore the argument for having a loader
that is capable of supporting other binary formats is not as strong as
it was years ago.
The question remains if all OSes that can load ELF binaries can also create
them.
>
> > What about the non-free OSes we support?
>
> What about them? I was unaware that _any_ Unix vendor's X server used the
> MetroLink loader, so it's not like we can use modules from Xsun with
> xorg-solaris. If this assumption is false I'd be very interested to know.
I'm not talking about vendor's X servers. The X.Org tree supports OSes
that have or don't have a native Xserver. Why one would like to replace
this one by X.Org's is another question, but if there wasn't a reason
the port would not exist.
>
> Going the other direction, the only closed MetroLink modules that exist (that

> I know of, again corrections welcomed) are for x86, and the only x86
> platforms where we run directly on the hardware are: the BSDs, Linux,
> Solaris/x86, old creaky SysV clones, and maybe OS/2. Of those, the ones that

> are currently shipping overwhelmingly use ELF for their native module format.

> So the ability to load non-native module formats doesn't buy you much,
> because all the world is an ELF system.
Maybe we should do a poll which OSes we support (we certainly have supported
more than have been build and tested recently) and see which binary formats
exist there. I acknowledge that this may be much less an issue than a few
years ago.
And you may very well be true it mostly matters on x86 - there the module
loader has been stable for a long time.
>
> Old systems can continue to use the old loader, and they'll be supported just

> as well as they ever were. All of the code changes that have been made to
> make the libdl modules work have been perfectly cross-compatible, meaning you

> can build an old-style module with debrix-drivers-ati and it'll work just
> fine.
>
> The difference in building an old-style module versus a new-style one is
> exactly equal to running ld instead of ar for the link stage. So - modulo
On x86 it's true. On most other platforms you will have to produce PIC
code - which cannot be handled by the old loader.
> bugfixes [1] - every closed binary driver vendor can instantly ship native
> modules just by adding three lines to the makefile. And vice versa;
> old-style modules are so easy to generate that there's no excuse to not build

> them.
>
> Which is fine, for the old decrepit platforms. But the MetroLink loader
> causes real problems for modern systems.
I'm aware of this as I ported the loader to AMD64.
>
> > I also would like to call for a careful evaluation of the situation.
> > Most of the people here belong to the Linux community so they probably
> > don't care.
>
> It's not that I don't care. If I didn't care I'd have nuked the old loader
> from debrix already. I have thought it through, and I don't see any major
> problems with making the native loader the default, but I've been wrong
> before so I'm willing to keep the old loader around as a backup.
Fine. That's definitely a wise decision.
Egbert.
Date: Mon Jul 12 05:31:42 2004
In-Reply-To: jbarnes@engr.sgi.com wrote on Wednesday,
7 July 2004 at 10:25:07 -0700
<200407071025.07089.jbarnes@engr.sgi.com>
Jesse Barnes writes:
> On Tuesday, July 6, 2004 9:36 am, Jon Smirl wrote:
> > --- John Dennis <jdennis@redhat.com> wrote:
> > > bus topology and that VGA routing is correct. Unlike the current
> >
> > You can't make the assumptions about VGA routing. When secondary video
> > cards are reset by running their ROM, at the very least they enable
> > their VGA support. Sometimes they remap the bridges too.
> >
> > We need kernel support for:
> > 1) disabling all VGA devices
> > 2) setting one VGA device active and get the bus routed to it
>
> This is possible, but also points out a deficiency in the current X server's
> idea of I/O ports. I spoke with John Dennis about this a few weeks ago, but
> it seems to me that we should either:
>
> o make the in/out routines take full pointers for the port address value
This is already done. All addresses in the code are already constructed
by using base+offset.
> - or -
> o pass a PCI tag to them so that the platform code can figure out where to
> route the I/O
I also had a similar idea years ago. However I dropped it again:
How about the latencies introduced when each IO operation has to
verify that it is routed correctly?
>
> As it stands, the X server's platform code has to assume one, global, I/O por
t
> base address...
>
Not true any more. Take a look at the AXP and PPC code. Possibly also the
IA64 code.
On these platforms PIO is 'redirected' to MMIO and each bus has its distinct
range in the MMIO address space.
Egbert.
Date: Mon Jul 12 05:34:10 2004
In-Reply-To: alan@lxorguk.ukuu.org.uk wrote on Wednesday,
7 July 2004 at 18:10:15 +0100
Alan Cox writes:
> On Llu, 2004-07-05 at 17:27, Jon Smirl wrote:
> > But now we end up building everything twice on Linux since fbdev needs
> > all of these things too. Then we have to spend time making the X and
> > fbdev versions play nice together. Plus, X's PCI bus manipulations are
> > in direct conflict with the Linux kernel.
>
> The more can be pushed to user space the easier that gets. BTW I've been
> looking at the PCI issue and there seems to be another lurking horror
> which could cause corruption on big AMD64 boxes and in some other cases.
> The BIOS emulation stuff (unless I've missed something
> here which is possible as its a first scan) doesn't seem to revector
> BIOS PCI conf1 access attempts via the kernel pci interface.
>
It does for 32bit accesses however not for 8 and 16bit ones.
So far this hasn't been a problem but you never know what those
BIOS guys come up with...
Also we don't catch conf2 access attempts - but so far I havn't
seen a BIOS that does these.
Egbert.
Date: Mon Jul 12 05:46:48 2004
>> So how does one make use of this radeonfb kernel module? Do I
>> need to build it into the kernel? The kernels Documentation dir,
>> and the drivers/video/aty dirs are both bareft of any mention of
>> this, as is the .config help.
>
>Building it into the kernel helps. Also, specify VGA_CONSOLE=N in .
>config.
Humm, turning it off isn't an option in a make xconfig, and
grepping .config for VGA returns this:
#CONFIG_FB_VGA16 is not set
CONFIG_VGA_CONSOLE=y
If I turn that off, do I still have a runlevel 3 login screen? My
kernel build script will allow me to revert one generation quite
easily. It makes sense that I'd still have the bios screen which
should be sufficient, so I'll edit that by hand and give it a shot.
--
Cheers, Gene
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jul 12 05:59:42 2004
Date: Mon Jul 12 05:59:46 2004
<16619.62786.869225.902850@xf11.fra.suse.de>
<16626.31085.431620.631904@xf11.fra.suse.de>
On Mon, 12 Jul 2004, Egbert Eich wrote:
> Alexander Gottwald writes:
> >
> > What about creating a new branch and rename it to the old? For cygwin we ha
ve
> > the same problem which I'm going to by branching from HEAD again and leave
> > the old CYGWIN branch dead (or move the branch tag to the new branch).
> >
>
> How do you rename a branch tag in CVS?
> It can be done easily with ordinary
> tags however I have not found a way
> to do this with branch tags.
I looked closer into it. I thought there was a way but only found a possibility
to
move the branch name to the new branch but this leaves the old branch without a
name.
bye
ago
--
Date: Mon Jul 12 06:05:33 2004
In-Reply-To: ajax@nwnk.net wrote on Friday, 9 July 2004 at 12:02:01 -0400
References: <16617.22371.859445.768739@hermes.local> <40EE0CB4.2030900@sun.com>
<Pine.LNX.4.58.0407090751240.1607@trantor.stuart.netsweng.com>
<200407091202.03070.ajax@nwnk.net>
>
> That's not the question though. The question is about binary-only device
> drivers, the ones that aren't in the X tree.
>
> Offhand, I believe the binary modules from ATI, Matrox, and PowerVR are
> x86-only and have a kernel component, which makes them not
> platform-independent.
>
Most of them (except for the NVIDIA driver) they will work without
the kernel module at least for 2D.
Egbert.
Date: Mon Jul 12 06:15:48 2004
In-Reply-To: alexander.gottwald@s1999.tu-chemnitz.de wrote on Wednesday,
7 July 2004 at 15:29:32 +0200
<16619.62786.869225.902850@xf11.fra.suse.de>
Alexander Gottwald writes:
>
> What about creating a new branch and rename it to the old? For cygwin we have
> the same problem which I'm going to by branching from HEAD again and leave
> the old CYGWIN branch dead (or move the branch tag to the new branch).
>
How do you rename a branch tag in CVS?
It can be done easily with ordinary
tags however I have not found a way
to do this with branch tags.
Egbert.
Date: Mon Jul 12 06:16:23 2004
On Sul, 2004-07-11 at 20:46, Eric Anholt wrote:
> One thing I've been talking with Kieth about is possibly supporting YUV
> surfaces in Render. I could see making them "special" so that YUV isn't
> a valid target to render to (no hardware I know of implements it),
The Xv surface on a lot of cards does and being able to use an Xv
surface as a screen lets you do some really wild things.
Other hardware examples
Zoran MJPEG chipsets (although some only do MJPEG)
IVTV (WinTV PVR series)
YUV422/420 (or YCbCr) frame buffers do show up in television and media
oriented devices. Currently you can drive them via shadowfb of course.
(Even in theory MJPEG although afaik nobody has done a Zoran MJPEG
shadowfb)
Date: Mon Jul 12 06:19:38 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don'tsupportit
in hardware...
In-Reply-To: <40F1A622.D213361F@nrubsig.org>
<40F1A622.D213361F@nrubsig.org>
> Depends... server-side image scaling is usually faster than client-side
> (assuming you make the images larger :) because you transfer _less_
> data. Much less...
It isnt that simple because in many cases the scaling and decoding
can be a single pass more efficiently. Its hard to gauge without someone
putting a really good scaler in X (not the X image extension stuff!)
If you have the time to try that experiment I'd be interested in the
results, although for modern hardware I suspect that the DRI layer or
OpenGL textures may be the way to go since that gives you access to
hardware scaling and format conversion
> If - and only "if" - MITSHM is available and suitable for the
> application. MITSHM itself is a PAIN on some OSes since the number and
> size of the shared segments is _limited_. IMHO MITSHM should go away,
> replaced by a shared memory X transport...
Heres $2 kid get yourself a real OS ;)
From sndirsch at suse.de Mon Jul 12 06:23:39 2004
From: sndirsch at suse.de (Stefan Dirsch)
Date: Mon Jul 12 06:24:19 2004
Subject: [Xorg] nvidia driver no longer works with current CVS?
Message-ID: <20040712132339.GA27480@suse.de>
Hi
I just updated to current CVS and recognized that the (binary-only)
nvidia driver for Linux no longer works with that version. Error
messages are:
Symbol vgaHWGetIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
Symbol vgaHWSave from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is unre
solved!
Symbol vgaHWRestore from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is u
nresolved!
Symbol vgaHWUnmapMem from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
Symbol fbCloseScreen from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
Symbol fbWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
Symbol fbCreateWindow from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
Symbol fbCreateGC from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is unr
esolved!
Symbol fbGCPrivateIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
Symbol fbValidateGC from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is u
nresolved!
Symbol fbPictureInit from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
Fatal server error:
I verified that the nvidia driver still works with CVS of 04-06-27,
but is at least broken with CVS of 04-07-07 and later. Simply using
the Xorg binary of 04-06-27 fixes the problem.
Anyone who is able to reproduce this? Any ideas which radical changes
might be responsible for this?
Stefan
Public Key available
----------------------------------------------------
Stefan Dirsch (Res. & Dev.) SUSE LINUX AG
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 N?rnberg
http://www.suse.de Germany
----------------------------------------------------
Date: Mon Jul 12 06:32:26 2004
>> On Monday 12 July 2004 06:04, Torgeir Veimo wrote:
>> >On Mon, 2004-07-12 at 05:52 -0400, Gene Heskett wrote:
>> >> So how does one make use of this radeonfb kernel module? Do I
>> >> need to build it into the kernel? The kernels Documentation
>> >> dir, and the drivers/video/aty dirs are both bareft of any
>> >> mention of this, as is the .config help.
>> >
>> >Building it into the kernel helps. Also, specify VGA_CONSOLE=N in
>> > . config.
>>
>> Humm, turning it off isn't an option in a make xconfig, and
>> grepping .config for VGA returns this:
>> #CONFIG_FB_VGA16 is not set
>> CONFIG_VGA_CONSOLE=y
>
>That's the correct one to turn off. Dont know why it isn't available
>with 'make xconfig'.
>
>> If I turn that off, do I still have a runlevel 3 login screen? My
>> kernel build script will allow me to revert one generation quite
>> easily. It makes sense that I'd still have the bios screen which
>> should be sufficient, so I'll edit that by hand and give it a
>> shot.
>
>You will have a console if you specify one in grub.conf. Try adding
>video=radeonfb.
I lost it at the exit from the grub choice screen, and didn't have any
visible output until the init script signed on, from there it was a
normal 80x25 screen. By specifying it, I lost the screen even
earlier, but either way it signs on with the INIT message. This
represents a potentially serious problem in that boot failure
messages usually occur in that range of the process. :(
>See eg here
>http://thesapphirecat.iwarp.com/present/program/radeonfb.html
This page seems to be quite old, no 2.6.x references at all.
But I'll give a couple of the options a try.
>I tried getting radeon framebuffer to work in 1280x720 but it's
>difficult as radeonfb seems to be made primarily for macs, and uses
> the timings and resolutions defined in the macmodes.h file, so I
> had to add that mode to that file.
--
Cheers, Gene
From jbarnes at engr.sgi.com Mon Jul 12 06:51:41 2004
Date: Mon Jul 12 06:52:46 2004
<16626.33905.967271.900052@xf11.fra.suse.de>
On Monday, July 12, 2004 5:30 am, Egbert Eich wrote:
> Jesse Barnes writes:
> > On Tuesday, July 6, 2004 9:36 am, Jon Smirl wrote:
> > > --- John Dennis <jdennis@redhat.com> wrote:
> > > > bus topology and that VGA routing is correct. Unlike the current
> > >
> > > You can't make the assumptions about VGA routing. When secondary video
> > > cards are reset by running their ROM, at the very least they enable
> > > their VGA support. Sometimes they remap the bridges too.
> > >
> > > We need kernel support for:
> > > 1) disabling all VGA devices
> > > 2) setting one VGA device active and get the bus routed to it
> >
> > This is possible, but also points out a deficiency in the current X
> > server's idea of I/O ports. I spoke with John Dennis about this a few
> > weeks ago, but it seems to me that we should either:
> >
> > o make the in/out routines take full pointers for the port address
> > value
>
> This is already done. All addresses in the code are already constructed
> by using base+offset.
In the arch specific in/out routines you mean? I see lots of lines like
inb(0x3c8) in various drivers and other code...
>
> > - or -
> > o pass a PCI tag to them so that the platform code can figure out
> > where to route the I/O
>
> I also had a similar idea years ago. However I dropped it again:
> How about the latencies introduced when each IO operation has to
> verify that it is routed correctly?
in/out is pretty slow already, and is only used at startup time, afaict. Most
code just does memory reads/writes to register space doesn't it?
>
> > As it stands, the X server's platform code has to assume one, global,
> > I/O port base address...
>
> Not true any more. Take a look at the AXP and PPC code. Possibly also the
> IA64 code.
Yeah, I'm looking at the ia64 stuff, it's still missing the necessary support.
It looks like ppc is still limited to doing legacy I/O (like the above inb)
to one bus.
> On these platforms PIO is 'redirected' to MMIO and each bus has its
> distinct range in the MMIO address space.
Right, I just wanted to make that more explicit.
Thanks,
Jesse
Date: Mon Jul 12 07:57:56 2004
Message-ID: <40F2A72B.6060304@sun.com>
Another thing that should be done for this release is determine
what we are doing about synchronizing with xterm & the new XKB
config files projects and getting in sync with them for this
release. (Are there any other bits that are separately maintained
that need to be brought up to date? Do we need to upgrade fontconfig
to the 2.2.3 release Keith just put out?)
--
From diegocg at teleline.es Mon Jul 12 07:59:20 2004
From: diegocg at teleline.es (Diego Calleja =?ISO-8859-15?Q?Garc=EDa?=)
Date: Mon Jul 12 07:59:14 2004
<1089624043.14848.103.camel@localhost>
Message-ID: <20040712165920.7f3ae4c8.diegocg@teleline.es>
El Mon, 12 Jul 2004 11:20:43 +0200 Michel D?nzer <michel@daenzer.net> escribi?:
> On Mon, 2004-07-12 at 05:06 -0400, Gene Heskett wrote:
> >
> > I've added a 'modprobe radeonfb' to my rc.local but haven't yet
> > rebooted. modprobing it while x is running (XFree86-4.3.2) resulted
> > in severe screen damages that required several screen switches to
> > fully recover,
>
> Sure, that's a bad idea. You're lucky nothing worse happened.
I have been seeing that behaviour for a while, when I modprobe radeonfb
from a Eterm inside Xfree almost everything goes black, things start reappearing
when they're redraw, I just change virtual desktops and most of the screen
seems to be redrawn w/o any problem (icewm window manager). In fact I've been
trying kdrive with the fb driver and it used to work - right now
in 2.6.7-mm7 it just hangs when I start kdrive (radeon 9200 se in a SMP p3)
from debian sid's Xfree dri enabled) but still I've not been able to get a
backtrace.
Date: Mon Jul 12 08:17:24 2004
[...]
>Yes the page is old, but the bottom section refering to 2.5 kernels
>should apply. Remember to use the fb suffix, eg radeonfb or vesafb.
> Have you tried vesafb btw?
>
>You can get most of the boot messages by using the dmesg command.
Which, if a reboot is done with the reset button while its apparently
hung during this period, will be overwritten long before it can be
read by rebooting to a known good configuration. That is not a
satisfactory solution IMO, so I will revert to the module that never
loads for some reason. And loaded or not, glxgears still runs in the
175-200 range. It should run 1000+. And tuxracer crashes the mouse
on exit in any event, requireing a reboot to restore the mouse.
In my last tests 6+ months back up the log, vesafb conflicted badly
with other framebuffers, disallowing one to ctrl-alt-fx out of x and
back, and usually results a system crash & a trip to the reset
button. In that case, I have usually been able to ssh into it from
the firewall and do a gracefull reboot _if_ I remember I can do it :(
--
Cheers, Gene
Date: Mon Jul 12 09:35:19 2004
> Jon Smirl writes:
> >
> > While trying to fix the radeonfb driver, BenH has run into some
> laptops
> > that take the system BIOS and VBIOS, put them into a single image,
> > compress it, and put it into a ROM. They can do this because the
> video
> > is build into the motherboard. I don't know how you are going to
> find
> > this without help from the system or using the C000:0 copy.
> >
>
> With some tricks (possibly by using the BIOS system vectors) you can
> often locate pages where the BIOS lives. Of course you can only use
> the pre-POSTED copy which lives somehwere beween 0xc0000 and 0xfffff.
>
> On these systems I have found that it is unwise to re-POST anyway
> as this may lead to undesireable results. In the best case the video
> BIOS tries to call into some vendor specific call in the system BIOS.
We know how to find the BIOS copy in low RAM. What you don't know is
which card it is associated with in a multiple graphics card system. To
track this a quirk needs to be added to the kernel which records which
device is the boot video device. The kernel need to track this since
device drivers can change the active VGA device and make another device
look like it was the boot device.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From don.ande at gmx.de Mon Jul 12 09:37:33 2004
From: don.ande at gmx.de (DonAnde)
Date: Mon Jul 12 09:38:07 2004
Subject: [Xorg] IBM rapidaccess 2 keyboard not detected properly
Message-ID: <1089650253.9676.198.camel@donande.vogelnest.lan>
Hello,
I,ve got the following problem:
My IBM rapidaccess 2 keyboard is not detected properly, so the skip,
play/pause and right-volume-multimedia-key don't work.
Under windows and xfree-4.3, the keys are working.
I use gentoo-linux.
xev don't give any results when I press the keys.
xorg.conf:
...
Driver "Keyboard"
Identifier "Keyboard[0]"
Option "MapName" "Standard Keyboard [ pc105 ]"
Option "Protocol" "Standard"
Option "XkbLayout" "de"
Option "XkbModel" "rapidaccess2"
Option "XkbVariant" "nodeadkeys"
EndSection
...
The other Xkb-settings don't work either.
Xorg.log
...
(**) |-->Input Device "Keyboard[0]"
(**) Option "Protocol" "Standard"
(**) Option "XkbRules" "xorg"
(**) XKB: rules: "xorg"
(**) Option "XkbModel" "rapidaccess2"
(**) XKB: model: "rapidaccess2"
(**) Option "XkbLayout" "de"
(**) XKB: layout: "de"
(**) Option "XkbVariant" "nodeadkeys"
(**) XKB: variant: "nodeadkeys"
(**) |-->Input Device "Mouse[1]"
...
The other multimedia-keys are working properly.
Does anybody got a hint for me?
Thanks in advance
greetings Andreas
Date: Mon Jul 12 09:45:00 2004
side widgets
In-Reply-To: <40F24370.1090007@Sun.COM>
--- Alan Coopersmith <Alan.Coopersmith@Sun.COM> wrote:
> require uid root priveledges. On x86, it requires root to get access
> to the PCI bus & card registers and memory mappings. (On SPARC, it's
> setgid root in order to do process priority adjustments and power
> control of the display & frame buffer.)
I'd like to work towards getting rid of the need to run root on X86
since it opens possible security holes. For example I'm slowly fixing
things so that DRI (and mesa-solo) doesn't need to be root. As far as I
know there is no absolute requirement to be root if the appropriate
pieces get pushed in the device driver.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From elylevy-xserver at cs.huji.ac.il Mon Jul 12 10:10:18 2004
Date: Mon Jul 12 10:10:23 2004
side widgets
are we talking about moving to user after login?
or always running as user?
how do you solve changing console ownership for eaxmple?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Mon, 12 Jul 2004, Jon Smirl wrote:
> --- Alan Coopersmith <Alan.Coopersmith@Sun.COM> wrote:
> > require uid root priveledges. On x86, it requires root to get access
> > to the PCI bus & card registers and memory mappings. (On SPARC, it's
> > setgid root in order to do process priority adjustments and power
> > control of the display & frame buffer.)
>
> I'd like to work towards getting rid of the need to run root on X86
> since it opens possible security holes. For example I'm slowly fixing
> things so that DRI (and mesa-solo) doesn't need to be root. As far as I
> know there is no absolute requirement to be root if the appropriate
> pieces get pushed in the device driver.
>
> =====
> Jon Smirl
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
>
> _______________________________________________
> xorg mailing list
>
From jdennis at redhat.com Mon Jul 12 10:43:57 2004
Date: Mon Jul 12 10:44:08 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don'tsupportit
in hardware...
In-Reply-To: <40F1A388.1F62B5C1@nrubsig.org>
<40F1A388.1F62B5C1@nrubsig.org>
> > > Are the "Xv" overlays _required_ to leave the underlying framebuffer
> > > contents intact ?
> >
> > No, most XV implementations paint a color key on the underlying
> > framebuffer,
>
> Who paints the color key ? The server-side part of "Xv" ?
Typically its the background pixel color of the Xv client application.
> Would it be possible to implement a "generic" codepath in Xv which
> renders the image using PutImage when there is no special support for Xv
> in the DDX ?
I used to work for a company that made set-top boxes running Linux and X
Windows. There are two basic problems with this approach we ran into.
Most video sources deliver their image data as YUV, not RGB, so you
would need color space conversion prior to PutImage (actually the shared
memory variant). It was a challenge with commodity hardware of about 2
years ago to do 30 FPS of color space conversion and PutImage operations
especially if the CPU was also decoding the video from a MPEG stream
(Linux 2.4 kernel scheduling was probably also a culprit). Devices which
support YUV framebuffers help enormously.
--
From roland.mainz at nrubsig.org Mon Jul 12 11:16:56 2004
Date: Mon Jul 12 11:17:10 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which don'tsupportitin
hardware...
Message-ID: <40F2D598.FAA9F3B7@nrubsig.org>
John Dennis wrote:
>
> > > > Are the "Xv" overlays _required_ to leave the underlying framebuffer
> > > > contents intact ?
> > >
> > > No, most XV implementations paint a color key on the underlying
> > > framebuffer,
> >
> > Who paints the color key ? The server-side part of "Xv" ?
>
> Typically its the background pixel color of the Xv client application.
No, I mean: Which "side" paints the color key ? The Xv implementation in
the Xserver or the X client ?
> > Would it be possible to implement a "generic" codepath in Xv which
> > renders the image using PutImage when there is no special support for Xv
> > in the DDX ?
>
> I used to work for a company that made set-top boxes running Linux and X
> Windows. There are two basic problems with this approach we ran into.
> Most video sources deliver their image data as YUV, not RGB, so you
> would need color space conversion prior to PutImage (actually the shared
> memory variant).
I am aware of the conversion problem... but it is still better than
having no Xv extension at all... :)
And it saves bandwidth in the case of remote X11...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Mon Jul 12 11:29:10 2004
side widgets
One idea being discussed is to use the kernel for login. Something like
SysReq or Ctrl-Alt-Del would be used to interrupt the kernel. The
kernel would then draw the login screen using a device drivers like
drm/fbdev. As part of the login process the ownership of the device
node would be transfered to the logged-in user.
No code has been written implementing this. It is just something that
is on the table for discussion at Kernel Summit.
Right now I'm just working on making the OpenGL drivers be able to run
without needing root.
--- Ely Levy <elylevy-xserver@cs.huji.ac.il> wrote:
> are we talking about moving to user after login?
> or always running as user?
> how do you solve changing console ownership for eaxmple?
>
> Ely Levy
> System group
> Hebrew University
> Jerusalem Israel
>
>
>
> On Mon, 12 Jul 2004, Jon Smirl wrote:
>
> > --- Alan Coopersmith <Alan.Coopersmith@Sun.COM> wrote:
> > > require uid root priveledges. On x86, it requires root to get
> access
> > > to the PCI bus & card registers and memory mappings. (On SPARC,
> it's
> > > setgid root in order to do process priority adjustments and power
> > > control of the display & frame buffer.)
> >
> > I'd like to work towards getting rid of the need to run root on X86
> > since it opens possible security holes. For example I'm slowly
> fixing
> > things so that DRI (and mesa-solo) doesn't need to be root. As far
> as I
> > know there is no absolute requirement to be root if the appropriate
> > pieces get pushed in the device driver.
> >
> > =====
> > Jon Smirl
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Address AutoComplete - You start. We finish.
> > http://promotions.yahoo.com/new_mail
> >
> > _______________________________________________
> >
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
Date: Mon Jul 12 11:43:53 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which
don'tsupportitin hardware...
In-Reply-To: <40F2D598.FAA9F3B7@nrubsig.org>
<40F2D598.FAA9F3B7@nrubsig.org>
> > Typically its the background pixel color of the Xv client application.
>
> No, I mean: Which "side" paints the color key ? The Xv implementation in
> the Xserver or the X client ?
As I said, the client. This is perhaps unfortunate, clearly it is the
ddx Xv implementation which has the knowledge about color keying, but
this is not the design of X where windows have backgrounds and those
backgrounds are automatically repainted by non Xv aware portions of the
server.
Date: Mon Jul 12 12:09:15 2004
> >
> > <snip>
> >
>
> I suspect that, in order to get consistent results, the gl*Pixels calls are
> implicitly preceeded by a glFinish call, which would impose a synchronization
> penalty.
Most contemporary hardware can insert draw pixels equivalent rendering
commands into the rendering data stream thus negating the need for
sync[1]. Reads that return pixel to the cpu still require a sync and
idle operation.
The real reason why the glPixel operations have traditionally been slow
are:
1) The pixel pipeline in OpenGL is a series of complex operations that
is non-trivial to optimize. I know, I did a lot of work in this area for
a certain vendor. It can be done, it just takes work, now to reason 2
...
2) The pixel pipeline does not affect the performance of games, which is
the design center for most OpenGL hardware and drivers, so why make an
engineering investment when there is little or no return?
[1] Just because hardware can support pixel operations in the rendering
stream it does not mean the considerable effort to support this has been
put into the driver.
--
Date: Mon Jul 12 12:14:11 2004
Subject: [Xorg] Implementing "Xv" extension on DDX which
don'tsupportitin hardware...
In-Reply-To: jdennis@redhat.com wrote on Monday,
12 July 2004 at 14:43:47 -0400
John Dennis writes:
> > > Typically its the background pixel color of the Xv client application.
> >
> > No, I mean: Which "side" paints the color key ? The Xv implementation in
> > the Xserver or the X client ?
>
> As I said, the client. This is perhaps unfortunate, clearly it is the
> ddx Xv implementation which has the knowledge about color keying, but
> this is not the design of X where windows have backgrounds and those
> backgrounds are automatically repainted by non Xv aware portions of the
> server.
This is not correct. The color key is entirely handeled witin the DDX
- or better to say the driver.
The XV extension is instructed to fill a certain drawable with data from
the video source. How this is done depends entirely on the underlaying
HW. Therefore letting the driver fill the visible areas of this drawable
with a color key is perfectly valid.
Egbert.
Date: Mon Jul 12 12:18:14 2004
In-Reply-To: <40F0B7C2.8080500@nospam.com>
References: <E1Bj9wd-0006IW-J9@evo.keithp.com> <40F0B7C2.8080500@nospam.com>
On Sat, 2004-07-10 at 23:45, Andy Sy wrote:
> I certainly would have to defer to the judgement of those who are
> more familiar with the API and the its implementation efficiency on
> different cards, but considering how ironic the fact that it is an
OpenGL was partitioned to be independent of the windowing system because
OpenGL is a rendering system ONLY and because OpenGL needed to co-exist
with existing windowing systems on various platforms.
A windowing system includes as one its many roles the task of rendering.
Assigning the task of rendering for a windowing system to a rendering
API which is windowing system neutral is completely consistent with the
design goals of OpenGL.
--
Date: Mon Jul 12 12:30:42 2004
> On Sat, 2004-07-10 at 23:45, Andy Sy wrote:
> > I certainly would have to defer to the judgement of those who are
> > more familiar with the API and the its implementation efficiency on
> > different cards, but considering how ironic the fact that it is an
> > API which was expressly developed to rely on an external 2D window
> > manager and is now being used to implement one itself, I believe
> > many would need more convincing as to its appropriateness.
>
> OpenGL was partitioned to be independent of the windowing system
> because OpenGL is a rendering system ONLY and because OpenGL
> needed to co-exist with existing windowing systems on various
> platforms.
>
> A windowing system includes as one its many roles the task of
> rendering. Assigning the task of rendering for a windowing system
> to a rendering API which is windowing system neutral is completely
> consistent with the design goals of OpenGL.
Think of X as a full screen app. This app then draws the windows using
the OpenGL drawing API. All of the clipping, compositing, etc is
handled in the X server.
Another way to look at it is to think of XAA as an API which supports
full screen drawing. Then X is implemented on top of XAA. OpenGL will
just replace XAA.
In reality things are more complex, but this is a simple way to think
about it.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Mon Jul 12 12:41:43 2004
Subject: Xserver needs to run as "root" on Linux / was: Re: [Xorg]
Server side widgets
On Mon, 2004-07-12 at 12:44, Jon Smirl wrote:
> As far as I
> know there is no absolute requirement to be root if the appropriate
> pieces get pushed in the device driver.
I'm still curious how in this model the performance issues that brought
the concept of "direct rendering" into existence will be addressed.
However, I do believe the issue is significantly mitigated with current
generation devices in which the GPU executes large DMA buffers of
rendering commands where the dispatch of these buffers occurs in a
driver with root privileges. By the way, this more typifies a 3D client
than what occurs with a 2D windowing system client in which large
batching is counter to expectations.
Maintaining optimal performance while balancing the balance of labor
between a driver and user level rendering process is tricky. How do you
propose to migrate things to a driver without degrading performance in
the general case?
The problem is that the transition between system and user is expensive
and if the operations performed by the driver are too small and fine
grained you're going to kill performance.
--
Date: Mon Jul 12 12:49:42 2004
Subject: [Xorg] Implementing "Xv" extension on DDX whichdon'tsupportitin
hardware...
<16626.58054.597904.341574@xf11.fra.suse.de>
Message-ID: <40F2EB43.D7EE9D2E@nrubsig.org>
Egbert Eich wrote:
> > > > Typically its the background pixel color of the Xv client application.
> > >
> > > No, I mean: Which "side" paints the color key ? The Xv implementation in
> > > the Xserver or the X client ?
> >
> > As I said, the client. This is perhaps unfortunate, clearly it is the
> > ddx Xv implementation which has the knowledge about color keying, but
> > this is not the design of X where windows have backgrounds and those
> > backgrounds are automatically repainted by non Xv aware portions of the
> > server.
>
> This is not correct. The color key is entirely handeled witin the DDX
> - or better to say the driver.
> The XV extension is instructed to fill a certain drawable with data from
> the video source. How this is done depends entirely on the underlaying
> HW. Therefore letting the driver fill the visible areas of this drawable
> with a color key is perfectly valid.
Egbert:
Does that mean that it's valid that a fallback implementation for Xv
simply converts YUV to RGB and renderes using the PutImage() hook ?
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Mon Jul 12 14:03:40 2004
In-Reply-To: <200407120651.41956.jbarnes@engr.sgi.com>
<16626.33905.967271.900052@xf11.fra.suse.de>
On Llu, 2004-07-12 at 14:51, Jesse Barnes wrote:
> In the arch specific in/out routines you mean? I see lots of lines like
> inb(0x3c8) in various drivers and other code...
There are some fun problems with the vga module and devices that can
relocate their vga registers too as with the SiS driver (and some good
discussion in the driver code)
> in/out is pretty slow already, and is only used at startup time, afaict. Most

> code just does memory reads/writes to register space doesn't it?
In iopl(3) mode out and in are pretty fast (obviously not as fast as
posted PCI mmio).
> Yeah, I'm looking at the ia64 stuff, it's still missing the necessary support.

> It looks like ppc is still limited to doing legacy I/O (like the above inb)
> to one bus.
Same with the IBM x440 if you use legacy addressing
Date: Mon Jul 12 14:05:28 2004
Server side widgets
On Llu, 2004-07-12 at 20:41, John Dennis wrote:
> On Mon, 2004-07-12 at 12:44, Jon Smirl wrote:
> > As far as I
> > know there is no absolute requirement to be root if the appropriate
> > pieces get pushed in the device driver.
>
> I'm still curious how in this model the performance issues that brought
> the concept of "direct rendering" into existence will be addressed.
Its also no magic bullet. Kernel code is considerably more of a security
issue than root code especially within an SELinux framework.
From krahn at niehs.nih.gov Mon Jul 12 13:28:12 2004
Date: Mon Jul 12 14:26:45 2004
Subject: [Xorg] XInput design updates
Message-ID: <40F2F45C.5030504@niehs.nih.gov>
I created two new Wiki pages for XInput, in addition to the
existing XInputHotplug page. Input from the X 'gurus' is appreciated.
I included various ideas from before Jim Gettys accepted the lead for
XFree86's XInput, along with some new ideas, and some feedback from
Kristian H?gsberg.
The first page focuses on updates to the XInput Extension specification.
Some of this has been discussed on the list:
http://freedesktop.org/XOrg/XInputSpec
The second page focuses on the server implementation and input drivers:
http://freedesktop.org/XOrg/XOrgInputDriverSpec
This includes a suggestion for Virtual core devices, which can solve a
lot of issues arising from differences in core and extension devices.
The input driver design differs from the current implementation.
It follows the original design documented in XInput, and is IMHO cleaner
than the current design. XFree86 never had an XInput driver design
document, so it has become very inconsistent. Surely there are a lot of
different opinions when it comes to software design, so I expect that
this document will evolve quite a bit before converging on a consensus.
Joe Krahn
From thomas at winischhofer.net Mon Jul 12 14:37:43 2004
Date: Mon Jul 12 14:39:30 2004
References: <20040706163604.56132.qmail@web14927.mail.yahoo.com> <2004070
71025.07089.jbarnes@engr.sgi.com> <16626.33905.967271.900052@xf11.fra.suse
.de> <200407120651.41956.jbarnes@engr.sgi.com>
Message-ID: <40F304A7.20205@winischhofer.net>
Alan Cox wrote:
> On Llu, 2004-07-12 at 14:51, Jesse Barnes wrote:
>
>>In the arch specific in/out routines you mean? I see lots of lines like
>>inb(0x3c8) in various drivers and other code...
These are arch-specific macros, defined in compiler.h.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net/
From nicolas at boichat.ch Mon Jul 12 15:51:17 2004
Date: Mon Jul 12 15:51:22 2004
Subject: [Xorg] DDC/CI on Linux
Message-ID: <1089672677.15753.42.camel@tom>
Hello,
I reverse-engineered a part of the DDC/CI protocol (this protocol is
used to control a monitor by software), and I wrote a tool for Linux.
You can download this tool here:
http://www.boichat.ch/nicolas/ddcci
This is not directly related to Xorg (I'm only using some kernel
drivers), but I think it will interest many people here.
Best regards,
Nicolas Boichat
Date: Mon Jul 12 19:08:48 2004
side widgets
> Its also no magic bullet. Kernel code is considerably more of a
> security
> issue than root code especially within an SELinux framework.
By isolating the privileged code into the driver there is much less of
it and it is much easier to inspect. The X server is a huge pile of
code that not very many people know how in detail how it all works. In
the driver model it is much easier to isolate and examine the code one
routine at a time.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Mon Jul 12 19:22:27 2004
Subject: Adding more features or more stability to the next X.org release ? /
was: Re: [Xorg] Next X.Org Foundation release plan
Message-ID: <40F34753.FFD8A281@nrubsig.org>
I am not sure whether "Composite" is ready. It seems there is still lots
of work todo and IMHO the next release should focus on _stability_, not
on a giant set of new features which don't work on many platforms or
with certain extensions (for example "SHAPE" vs. "Composite").
Lots of libraries and other stuff has been added or updated since
X11R6.7.0 and it may be better to ship a stabilised version of the
current tree as X11R6.7.1 and then think about adding new features (like
"Composite") step-by-step. Small steps, please... :)
BTW: This reminds me to say that nearly one third of the platforms which
should be supported by the Xorg tree in _theory_ do not work: For
example MacOSX and SCO do not build... and don't even ask about the
status of the AIX platform.
And the tinderbox at http://tinderbox.freedeskto.org/ currently is a
NO-OP and noone seems to care even when it is building... ;-(
----
bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Mon Jul 12 19:22:55 2004
side widgets
> Maintaining optimal performance while balancing the balance of labor
> between a driver and user level rendering process is tricky. How do
> you propose to migrate things to a driver without degrading
> performance in the general case?
>
> The problem is that the transition between system and user is
> expensive and if the operations performed by the driver are too
> small and fine grained you're going to kill performance.
It may be the case that we are better off leaving the 2D cards handled
by XAA alone. This work is primarily aimed at DMA based 3D cards with
DRI support.
On the other hand, a composited windowing system may completely change
the performance profiles. For 2D cards it will probably be better if
the application windows are drawn into system memory. Then only the
compositing step would touch the video memory.
For 3D hardware it is better if the app windows are in offscreen video
memory where hardware assisted drawing can be used. These are also the
cards with DMA control.
In this model the 2D video driver only needs to very efficiently
support the Porter-Duff compositing operations. All of the commands to
build a screen will also be batched together since compositing implies
double buffering. It may be possible to issue on a single IOCTL per
screen if the IOCTL contains a list of rectangles in system memory that
need to be composited.
I've asked Keithp about how damage is going to work in a double
buffered system where the main screen you want to update is one frame
behind. He's still thinking about the answer.
No one has done any work in this direction on 2D hardware. Most of the
focus is on the 3D cards.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
Date: Mon Jul 12 20:30:09 2004
On Monday, July 12, 2004 4:00 pm, Alan Cox wrote:
> On Llu, 2004-07-12 at 14:51, Jesse Barnes wrote:
> > In the arch specific in/out routines you mean? I see lots of lines like
> > inb(0x3c8) in various drivers and other code...
>
> There are some fun problems with the vga module and devices that can
> relocate their vga registers too as with the SiS driver (and some good
> discussion in the driver code)
Ooh, fun.
> > in/out is pretty slow already, and is only used at startup time, afaict.
> > Most code just does memory reads/writes to register space doesn't it?
>
> In iopl(3) mode out and in are pretty fast (obviously not as fast as
> posted PCI mmio).
But do any drivers use it as their primary mechanism for talking with their
device? At any rate, I think we can do it in such a way that in/out
performance isn't adversely affected.
> > Yeah, I'm looking at the ia64 stuff, it's still missing the necessary
> > support. It looks like ppc is still limited to doing legacy I/O (like the
> > above inb) to one bus.
>
> Same with the IBM x440 if you use legacy addressing
On sn2 at least, we're not prevented by hardware from doing legacy I/O to
multiple busses at the same time, I wonder if other platforms are the same?
I seemed to gather from talking with benh that ppc could do better if given
the chance...
So, in short, unless there are problems, I'd like to see things like
val = inb(0x3c8)
changed to
iobase = xf86GetLegacyIOBase(Tag);
...
val = inb(iobase + 0x3c8)
*or*
val = inb(Tag, 0x3c8)
(The latter would probably be slower, as was already mentioned.)
Is that possible? It seems like we could move the current iopl(3) stuff to
that function. On x86, that'd be pretty much all that function did, but on
other platforms it would allow per-device legacy I/O spaces. I don't think
it would hurt drivers like SiS either, since they'd just be changing the
constant they added to the iobase variable, rather than the base itself,
right?
Jesse
From justus at gmx.li Tue Jul 13 01:00:43 2004
From: justus at gmx.li (justus schwartz)
Date: Tue Jul 13 01:01:08 2004
Subject: [Xorg] radeon mobility 9000 M9 + dvi out
Message-ID: <87658s5ob8.fsf@gmx.li>
hi!
i spend the last day trying to get the dvi connector of my radon working. the
dvi out is on the port replicator for my ibm t40p notebook which has also an
analog vga out.
connecting the monitor to the analog vga works fine, but connecting to the dvi
out doesn't work (i am trying with the newest x.org cvs and MergedFB, i'll put
my config on a webserver). the dvi port is working because the ddc module is
able to read the data from the monitor. if i have it connected to both dvi and
vga, it even reads the data two times.
i started looking at the source of the radeon driver but got a bit lost :) is
it supposed to work? if not maybe somebody could give me a hint what to look at.
the complete xserver log and the config are at
http://honeybunny.inf.ethz.ch/~justus/tmp/xorg/Xorg.0.log
(yes DRI isn't working at the moment, but i don't worry about that at the
moment) and
http://honeybunny.inf.ethz.ch/~justus/tmp/xorg/Xorg.conf
a second problem i would like to solve is, that because of the bigger virtual
desktop size the notebook lcd is "scrolling with mouse movement" (i think you
know what i mean). i'd like to fix its position (like it is possible when using
xinerama).
thx for any hints
ciao
-justus
--
int m,o,O=0;float l,I,_;main(){for(;1840-O;putchar((++O>907&&936>O?61-m:o)
["\rX-#!*X'bc)jrs)inG}sufpodt'''trstrM"]^7))for(o=I=l=0;79-(m=O%80)&&_*l+I*
I<6&&26-++o;I=2*l*I+O/80*.09-1,l=_)_=l*l-I*I-2+m/27.;}
From torgeir at pobox.com Tue Jul 13 04:01:06 2004
Date: Tue Jul 13 04:01:12 2004
Server side widgets
On Mon, 2004-07-12 at 11:29 -0700, Jon Smirl wrote:
> e idea being discussed is to use the kernel for login. Something like
> SysReq or Ctrl-Alt-Del would be used to interrupt the kernel. The
> kernel would then draw the login screen using a device drivers like
> drm/fbdev. As part of the login process the ownership of the device
> node would be transfered to the logged-in user.
Wouldn't it be better to leave control to a separate program after a
sys-req event, like init, and use a special run-level? A separate
program could then handle both text mode and graphical login?
--
From andy at nospam.com Tue Jul 13 04:18:32 2004
Date: Tue Jul 13 04:11:42 2004
Message-ID: <40F3C508.5090404@nospam.com>
John Dennis wrote:
> Assigning the task of rendering for a windowing system to a rendering
> API which is windowing system neutral is completely consistent with the
> design goals of OpenGL.
The task in question is not merely rendering /for/ a windowing system.
It's rendering /the/ windowing system itself. So again, the question
is, how suitable and how efficiently implemented is the OpenGL API
(built mainly with *3D* rendering in mind) for the task of _implementing_
a 2D windowing system.
My main worries are that 2D operations might be klunkier or less
efficient (considering the horror stories I've heard about the
performance of glXXXXPixels()) to execute using the OpenGL API.
If Quartz Extreme is indeed completely implemented via the OpenGL
API then that bodes well. On the other hand, if it relies on even
one or two non-standard or non-OpenGL API functions / extensions
for basic or key functionality, then it is virtually a sure bet that
the designers of Quartz Extreme have found out that one cannot
efficiently or elegantly implement a windowing system on top of
/pure/ OpenGL (i.e. that the OpenGL API lacks certain suitable
kinds of calls for such a task).
--
From rjw57 at hermes.cam.ac.uk Tue Jul 13 04:35:22 2004
From: rjw57 at hermes.cam.ac.uk (Rich Wareham)
Date: Tue Jul 13 04:31:40 2004
In-Reply-To: <40F3C508.5090404@nospam.com>
<40F3C508.5090404@nospam.com>
Message-ID: <20040713113522.GA8123@hermes.cam.ac.uk>
On Tue, Jul 13, 2004 at 07:18:32PM +0800, Andy Sy wrote:
> John Dennis wrote:
>
> >Assigning the task of rendering for a windowing system to a rendering
> >API which is windowing system neutral is completely consistent with the
> >design goals of OpenGL.
>
> The task in question is not merely rendering /for/ a windowing system.
> It's rendering /the/ windowing system itself. So again, the question
> is, how suitable and how efficiently implemented is the OpenGL API
> (built mainly with *3D* rendering in mind) for the task of _implementing_
> a 2D windowing system.
>
> My main worries are that 2D operations might be klunkier or less
> efficient (considering the horror stories I've heard about the
> performance of glXXXXPixels()) to execute using the OpenGL API.
Disclaimer: all of this is IMHO, based on hacking around with OpenGL for
my PhD.
The 2D operations are, in fact, just generalisations of the 3d ones.
Switch to orthographic projection, turn off the z-buffer, use glVertex2*
and friends, etc and things can be just as fast, probably faster (since
there is no z-buffer writes) as 3d.
cf. the fact that most OpenGL games implement a windowed UI for settings
etc, in OpenGL that is perfectly responsive.
The concern about reading back from the framebuffer might be valid
since, clearly, this isn't a prime target for most games so that may
well be optimised somewhat less in a particular implementation. OTOH,
p-buffers and the like might possibly be used if someone could be
cunning.
About the only problem I can foresee is that standard OpenGL only
supports 2**n x 2**n textures although that can be overcome by some
cunningness (maintain a set of textures and 'stitch' windows together
from parts of them).
Of course none of this negates the fact that there are a set of older
cards which have only 2d acceleration. I guess the question is if people
want to force users of these to accept software rendered OpenGL or
whether a sufficient subset of OpenGL can be specified that can be
implemented on 2D only hardware.
Quartz Extreme /does/ use OpenGL-kinda for its window server but not
directly. More precisely the Apple openGL implementation and the window
server co-operate when talking direct to the graphics driver.
--
Rich
Date: Tue Jul 13 04:57:42 2004
Server side widgets
On Mon, 2004-07-12 at 19:22 -0700, Jon Smirl wrote:
> > Maintaining optimal performance while balancing the balance of labor
> > between a driver and user level rendering process is tricky. How do
> > you propose to migrate things to a driver without degrading
> > performance in the general case?
> >
> > The problem is that the transition between system and user is
> > expensive and if the operations performed by the driver are too
> > small and fine grained you're going to kill performance.
I think this problem has been very well explored and solved in the DRI
drivers. So long as OpenGL isn't used too pathologically, I don't
foresee major problems there.
> I've asked Keithp about how damage is going to work in a double
> buffered system where the main screen you want to update is one frame
> behind. He's still thinking about the answer.
Actually, the point is page flipping as opposed to copying the back
buffer to the front buffer for each frame, isn't it? I tend to think the
answer is to just draw the whole screen contents for each frame; of
course, the area that hasn't changed can be copied from the previous
frame when that requires less effort than drawing everything from
scratch.
--
From msipkema at sipkema-digital.com Tue Jul 13 06:01:25 2004
From: msipkema at sipkema-digital.com (Martijn Sipkema)
Date: Tue Jul 13 05:03:01 2004
Message-ID: <020e01c468d9$823b41d0$161b14ac@boromir>
Jon Smirl wrote:
> > On Sat, 2004-07-10 at 23:45, Andy Sy wrote:
> > > I certainly would have to defer to the judgement of those who are
> > > more familiar with the API and the its implementation efficiency on
> > > different cards, but considering how ironic the fact that it is an
> > > API which was expressly developed to rely on an external 2D window
> > > manager and is now being used to implement one itself, I believe
> > > many would need more convincing as to its appropriateness.
> >
> > OpenGL was partitioned to be independent of the windowing system
> > because OpenGL is a rendering system ONLY and because OpenGL
> > needed to co-exist with existing windowing systems on various
> > platforms.
> >
> > A windowing system includes as one its many roles the task of
> > rendering. Assigning the task of rendering for a windowing system
> > to a rendering API which is windowing system neutral is completely
> > consistent with the design goals of OpenGL.
>
> Think of X as a full screen app. This app then draws the windows using
> the OpenGL drawing API. All of the clipping, compositing, etc is
> handled in the X server.
I don't think this would be an ideal solution. You would not be able to
use hardware clipping or support a framebuffer with more than one pixel
format.
> Another way to look at it is to think of XAA as an API which supports
> full screen drawing. Then X is implemented on top of XAA. OpenGL will
> just replace XAA.
Would it not be nicer to have a library for setting up the framebuffer and
allocating windows and have OpenGL draw into these windows? That
would also allow applications to render directly into the framebuffer.
--ms
Date: Tue Jul 13 05:03:52 2004
side widgets
--- Torgeir Veimo <torgeir@pobox.com> wrote:
> On Mon, 2004-07-12 at 11:29 -0700, Jon Smirl wrote:
> > e idea being discussed is to use the kernel for login. Something
> like
> > SysReq or Ctrl-Alt-Del would be used to interrupt the kernel. The
> > kernel would then draw the login screen using a device drivers like
> > drm/fbdev. As part of the login process the ownership of the device
> > node would be transfered to the logged-in user.
>
> Wouldn't it be better to leave control to a separate program after a
> sys-req event, like init, and use a special run-level? A separate
> program could then handle both text mode and graphical login?
The idea of a kernel based login is that it is completely secure and
can't be trojaned. A key that can't be intercepted is used to trigger
login. The kernel catches this and clears/draws the screen in a way
that can't be stopped. The keyboard is then directly read for the login
data.
>
> --
> Torgeir Veimo <torgeir@pobox.com>
>
>
> _______________________________________________
> xorg mailing list
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From alexdeucher at gmail.com Tue Jul 13 06:03:23 2004
Date: Tue Jul 13 06:03:42 2004
In-Reply-To: <87658s5ob8.fsf@gmx.li>
References: <87658s5ob8.fsf@gmx.li>
Message-ID: <a728f9f9040713060378c990e1@mail.gmail.com>
On Tue, 13 Jul 2004 10:00:43 +0200, justus schwartz <justus@gmx.li> wrote:
> hi!
>
> i spend the last day trying to get the dvi connector of my radon working. the
> dvi out is on the port replicator for my ibm t40p notebook which has also an
> analog vga out.
>
> connecting the monitor to the analog vga works fine, but connecting to the dvi
> out doesn't work (i am trying with the newest x.org cvs and MergedFB, i'll put
> my config on a webserver). the dvi port is working because the ddc module is
> able to read the data from the monitor. if i have it connected to both dvi and
> vga, it even reads the data two times.
>
> i started looking at the source of the radeon driver but got a bit lost :) is
> it supposed to work? if not maybe somebody could give me a hint what to look a
t.
The improved crtc handling in ati's latest code drop may help in this
situation. Also when using a DVI port, I think crtc1actually drives
the DVI port and crtc2 drives the LCD. you might want to try:
Option MonitorLayout "TMDS, LVDS"
however, I'm not sure the crtc code in cvs can properly handle output
swaps at the moment.
>
> the complete xserver log and the config are at
>
> http://honeybunny.inf.ethz.ch/~justus/tmp/xorg/Xorg.0.log
>
> (yes DRI isn't working at the moment, but i don't worry about that at the
> moment) and
>
> http://honeybunny.inf.ethz.ch/~justus/tmp/xorg/Xorg.conf
>
> a second problem i would like to solve is, that because of the bigger virtual
> desktop size the notebook lcd is "scrolling with mouse movement" (i think you
> know what i mean). i'd like to fix its position (like it is possible when usin
g
> xinerama).
I suspect the mergedfb support in cvs may be somewhat broken.
Unfortunately, I haven't had a chance to test and fix it yet. this
also may be related to the reversed crtc mappings I mentioned above.
Alex
>
> thx for any hints
> ciao
> -justus
>
> --
> int m,o,O=0;float l,I,_;main(){for(;1840-O;putchar((++O>907&&936>O?61-m:o)
> ["\rX-#!*X'bc)jrs)inG}sufpodt'''trstrM"]^7))for(o=I=l=0;79-(m=O%80)&&_*l+I*
> I<6&&26-++o;I=2*l*I+O/80*.09-1,l=_)_=l*l-I*I-2+m/27.;}
>
> _______________________________________________
> xorg mailing list
>
Date: Tue Jul 13 06:53:45 2004
side widgets
Message-ID: <40F3E961.6010009@toya.net.pl>
Jon Smirl wrote:
> --- Torgeir Veimo <torgeir@pobox.com> wrote:
>
>>On Mon, 2004-07-12 at 11:29 -0700, Jon Smirl wrote:
>>
>>>e idea being discussed is to use the kernel for login. Something like
>>>SysReq or Ctrl-Alt-Del would be used to interrupt the kernel. The
>>>kernel would then draw the login screen using a device drivers like
>>>drm/fbdev. As part of the login process the ownership of the device
>>>node would be transfered to the logged-in user.
>>
>>Wouldn't it be better to leave control to a separate program after a
>>sys-req event, like init, and use a special run-level? A separate
>>program could then handle both text mode and graphical login?
>
> The idea of a kernel based login is that it is completely secure and
> can't be trojaned. A key that can't be intercepted is used to trigger
> login. The kernel catches this and clears/draws the screen in a way
> that can't be stopped. The keyboard is then directly read for the login
> data.
Looks really Windowish (and fishy) to me...
Why is this better than x/g/w/xdm? AFAIR from the beggining Unixes used
(min)getty+login for logging in on text terminals and it works without
problems (I can event change mingetty to fbgetty to get some fancy
graphic into the framebuffer).
What make graphic consoles different?
--
Regrads,
Jakub Piotr C?apa
From elanthis at awesomeplay.com Tue Jul 13 07:06:22 2004
Date: Tue Jul 13 07:06:31 2004
Server side widgets
In-Reply-To: <40F3E961.6010009@toya.net.pl>
<40F3E961.6010009@toya.net.pl>
On Tue, 2004-07-13 at 09:53, Jakub Piotr C=C5=82apa wrote:
> Jon Smirl wrote:
> > The idea of a kernel based login is that it is completely secure and
> > can't be trojaned. A key that can't be intercepted is used to trigger
> > login. The kernel catches this and clears/draws the screen in a way
> > that can't be stopped. The keyboard is then directly read for the login
> > data.
>=20
> Looks really Windowish (and fishy) to me...
>=20
> Why is this better than x/g/w/xdm? AFAIR from the beggining Unixes used=20
I log in. I make a program that paints a full-screen window identical
to GDM, but it takes the user names/passwords and mails them to me. A
user sits down, tries to log in, and poof, I stole their login
information.
This is why Windows has the "Push ctrl-alt-delete to login" window on
most corporate workstations. The kernel and _only_ the kernel can catch
and process ctrl-alt-delete.
I'm not at all convinced that the actual login screen and daemon needs
to be in the kernel at all, but there does need to be a way to 100%
guarantee that you are at the real login screen; kernel-level checks
using a kernel-only key sequence is one way to do this. Perhaps the
kernel can, upon receiving the key-combination, open a new VT and launch
a specific binary (GDM/KDM/etc) on it? The only way to trojan that
would be to over-write the login manager binaries or somehow get access
to control a VT owned by root/login-manager-user, which shouldn't be any
easier than cracking the kernel login system, no?
> (min)getty+login for logging in on text terminals and it works without=20
> problems (I can event change mingetty to fbgetty to get some fancy=20
> graphic into the framebuffer).
> What make graphic consoles different?
Nothing. The security problem is there with mingetty as well. The same
system discussed here could potentially be used to alleviate that
problem as well.
--=20
From justus at gmx.li Tue Jul 13 07:15:12 2004
From: justus at gmx.li (justus schwartz)
Date: Tue Jul 13 07:15:32 2004
In-Reply-To: <a728f9f9040713060378c990e1@mail.gmail.com> (Alex Deucher's
message of "Tue, 13 Jul 2004 09:03:23 -0400")
References: <87658s5ob8.fsf@gmx.li> <a728f9f9040713060378c990e1@mail.gmail.com>
Message-ID: <87fz7w3sen.fsf@gmx.li>
hi!
Alex Deucher <alexdeucher@gmail.com> writes:
> The improved crtc handling in ati's latest code drop may help in this
> situation. Also when using a DVI port, I think crtc1actually drives
> the DVI port and crtc2 drives the LCD. you might want to try:
> Option MonitorLayout "TMDS, LVDS"
> however, I'm not sure the crtc code in cvs can properly handle output
> swaps at the moment.
thank you. trying this i get a very bad picture using dvi in of the monitor and
the normal picture switching to the vga in of the monitor (and nothing on the
lcd). i haven't understood how the code handels cases where there are 3
monitors available (on the dvi, the vga port and the internal lcd) i've seen
only two structs for reading the monitor data.
> I suspect the mergedfb support in cvs may be somewhat broken.
> Unfortunately, I haven't had a chance to test and fix it yet. this
> also may be related to the reversed crtc mappings I mentioned above.
ok thx. mergedfb is working so far. i am only missing some more options for
the placement of the monitors ;) (eg. fixed position vs scrolling (if this is
possible))
i'll just wait, as far as i understood mergedfb is fairly new...
so long
-justus
--
int m,o,O=0;float l,I,_;main(){for(;1840-O;putchar((++O>907&&936>O?61-m:o)
["\rX-#!*X'bc)jrs)inG}sufpodt'''trstrM"]^7))for(o=I=l=0;79-(m=O%80)&&_*l+I*
I<6&&26-++o;I=2*l*I+O/80*.09-1,l=_)_=l*l-I*I-2+m/27.;}
From Nicolas.Mailhot at laPoste.net Tue Jul 13 07:44:51 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Tue Jul 13 07:51:16 2004
Server side widgets
<40F3E961.6010009@toya.net.pl>
<1089727581.15710.7.camel@support02.civic.twp.ypsilanti.mi.us>
Message-ID: <1089729892.9188.18.camel@ulysse.olympe.o2t>
Le mar, 13/07/2004 ? 10:06 -0400, Sean Middleditch a ?crit :
> This is why Windows has the "Push ctrl-alt-delete to login" window on
> most corporate workstations. The kernel and _only_ the kernel can catch
> and process ctrl-alt-delete.
Assuming the link from the keyboard to the computer and from the
computer to the screen is safe (which in the brave new wireless world is
less and less true)
A minimalist security feature would probably be for the system to ack
local logins with a passphrase the user entered when his account was
created. It would not protect against interception but at least you'd
know the real system was in the loop somewhere.
The sad fact is you can't really secure a system with as dumb a device
as a low-cost ps/2 keyboard. That's why smart card readers have a
dedicated keyboard/display
Regards,
--
Nicolas Mailhot
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://freedesktop.org/pipermail/xorg/attachments/20040713/9e3db06b/attach
ment.pgp
Date: Tue Jul 13 08:06:48 2004
Server side widgets
In-Reply-To: <1089729892.9188.18.camel@ulysse.olympe.o2t>
<40F3E961.6010009@toya.net.pl>
<1089729892.9188.18.camel@ulysse.olympe.o2t>
On Tue, 2004-07-13 at 10:44, Nicolas Mailhot wrote:
> Le mar, 13/07/2004 =C3=A0 10:06 -0400, Sean Middleditch a =C3=A9crit :
>=20
> > This is why Windows has the "Push ctrl-alt-delete to login" window on
> > most corporate workstations. The kernel and _only_ the kernel can catc=
h
> > and process ctrl-alt-delete.
>=20
> Assuming the link from the keyboard to the computer and from the
> computer to the screen is safe (which in the brave new wireless world is
> less and less true)
Although this is incredibly rare in the corporate world, and likely to
stay that way. Securing the hardware is also possible, as you hinted at
below. Keyboard connections could very well be encrypted, with the
kernel refusing any keyboard input from keyboards with a different
encryption key. Just because the current crop of hardware is easy to
hack doesn't mean we have to let our software suck at security, too.=20
;-)
And, really, securing the software only has a lot of bang for the
effort. It's very, very easy to just download a fake login manager and
run it, compared to installing a hardware-level hack. No security is
ever 100%; the best you can do is deter crackers.
> A minimalist security feature would probably be for the system to ack
> local logins with a passphrase the user entered when his account was
> created. It would not protect against interception but at least you'd
> know the real system was in the loop somewhere.
Except those would be so easy to steal and then put in the fake login
manager to be worthless. Just watch over your co-worker's shoulder as
they login and get the pass-phrase to display.
>=20
> The sad fact is you can't really secure a system with as dumb a device
> as a low-cost ps/2 keyboard. That's why smart card readers have a
> dedicated keyboard/display
>=20
> Regards,
--=20
From elylevy-xserver at cs.huji.ac.il Tue Jul 13 08:07:50 2004
Date: Tue Jul 13 08:07:54 2004
side widgets
In-Reply-To: <1089729892.9188.18.camel@ulysse.olympe.o2t>
<40F3E961.6010009@toya.net.pl>
Message-ID: <Pine.LNX.4.56.0407131806140.1507@gx-112.cs.huji.ac.il>
On Tue, 13 Jul 2004, Nicolas Mailhot wrote:
> Le mar, 13/07/2004 =C3=A0 10:06 -0400, Sean Middleditch a =C3=A9crit :
>
> > This is why Windows has the "Push ctrl-alt-delete to login" window on
> > most corporate workstations. The kernel and _only_ the kernel can catc=
h
> > and process ctrl-alt-delete.
>
> Assuming the link from the keyboard to the computer and from the
> computer to the screen is safe (which in the brave new wireless world is
> less and less true)
> A minimalist security feature would probably be for the system to ack
> local logins with a passphrase the user entered when his account was
> created. It would not protect against interception but at least you'd
> know the real system was in the loop somewhere.
And someone would just pick over your shoulder and see it?
> The sad fact is you can't really secure a system with as dumb a device
> as a low-cost ps/2 keyboard. That's why smart card readers have a
> dedicated keyboard/display
Ofcourse, but it doesn't mean we are going to cancell passwords cause of
it.
We should do the best we can with the hardware that is there.
> Regards,
>
> --
> Nicolas Mailhot
Ely
Date: Tue Jul 13 08:22:47 2004
side widgets
References: <20040713120350.38834.qmail@web14927.mail.yahoo.com> <40F3E96
1.6010009@toya.net.pl>
Message-ID: <40F3FE43.2040206@toya.net.pl>
> On Tue, 2004-07-13 at 09:53, Jakub Piotr C??apa wrote:
>
>>Jon Smirl wrote:
>
>>>The idea of a kernel based login is that it is completely secure and
>>>can't be trojaned. A key that can't be intercepted is used to trigger
>>>login. The kernel catches this and clears/draws the screen in a way
>>>that can't be stopped. The keyboard is then directly read for the login
>>>data.
>>
>>Looks really Windowish (and fishy) to me...
>>
>>Why is this better than x/g/w/xdm? AFAIR from the beggining Unixes used
>
> I log in. I make a program that paints a full-screen window identical
> to GDM, but it takes the user names/passwords and mails them to me. A
> user sits down, tries to log in, and poof, I stole their login
> information.
>
>
> I'm not at all convinced that the actual login screen and daemon needs
> to be in the kernel at all, but there does need to be a way to 100%
> guarantee that you are at the real login screen; kernel-level checks
> using a kernel-only key sequence is one way to do this. Perhaps the
> kernel can, upon receiving the key-combination, open a new VT and launch
> a specific binary (GDM/KDM/etc) on it? The only way to trojan that
> would be to over-write the login manager binaries or somehow get access
> to control a VT owned by root/login-manager-user, which shouldn't be any
> easier than cracking the kernel login system, no?
Thanks for explaining this. I think I understand now. :)
Some random thoughts:
What if somebody writes a local exploit? On what systems exposed to such
malicious users you allow them to run their own code? (ok... you could
possibly mimic the login screen in flash or sth. like that...)
What's wrong with currently available Ctrl-Alt-Backspace? It would kill
such a malicious session and you will be sure the thing that shows up on
the screen is same thing somebody with root access have set.
Basically we need something to kill everything that is running on the
current virtual terminal and respawn whatever there should be - thats a
better overall sollution. (it would probably require login managers to
be spawned by init and not allocating consoles by themselves, but that
could be a good idea anyway)
Of course the problem is nonexistant if we login with some kind of a
token (or any other device used only to log in i.e. innaccessible to
nonroot programs).
--
Regards,
Jakub Piotr C?apa
Date: Tue Jul 13 08:30:11 2004
Subject: Xserver needs to run as "root" on Linux / was: Re:
[Xorg] Server side widgets
In-Reply-To: <40F3FE43.2040206@toya.net.pl>
<40F3E961.6010009@toya.net.pl>
<40F3FE43.2040206@toya.net.pl>
> Some random thoughts:
>=20
> What if somebody writes a local exploit? On what systems exposed to such=20
> malicious users you allow them to run their own code? (ok... you could=20
> possibly mimic the login screen in flash or sth. like that...)
It's impossible to stop users from running code. If nothing else, you
can manually run ld-so with your binary as input. Other than using
something like SELinux, which even then (given how sickeningly complex
it is for even its creators to configure properly on multi-purpose
machines) will likely have many holes.
>=20
> What's wrong with currently available Ctrl-Alt-Backspace? It would kill=20
> such a malicious session and you will be sure the thing that shows up on=20
> the screen is same thing somebody with root access have set.
Nope. I can switch to a text console and write a script that launches a
new X session with my fake login program in a loop. kill the X server,
the script just relaunches it. Again, no way to tell if it's my hack or
the real login server.
>=20
> Basically we need something to kill everything that is running on the=20
> current virtual terminal and respawn whatever there should be - thats a=20
> better overall sollution. (it would probably require login managers to=20
> be spawned by init and not allocating consoles by themselves, but that=20
> could be a good idea anyway)
And then we have a minor security hole in that a user can switch to some
console another user might be using (but have locked) and kill
everything running there. (And, before you ask, it is possible to turn
off the ctrl-alt-backspace to protect against this as well.)
>=20
> Of course the problem is nonexistant if we login with some kind of a=20
> token (or any other device used only to log in i.e. innaccessible to=20
> nonroot programs).
Which is more expensive and difficult to setup than simply installing
your OS and having it's login system (relatively) secure by default.=20
The more difficult it is to secure the machine by the administrator, the
less likely it is to be secure. Such login devices are already
available, and high-security networks use them. Login protections like
we're discussing are more helpful for the average network, where special
hardware is rare and software protections are about all you'll find. We
can't make them 100% secure, but we can help them be more secure than
they were previously.
--=20
From diegocg at teleline.es Tue Jul 13 08:24:21 2004
From: diegocg at teleline.es (Diego Calleja =?ISO-8859-15?Q?Garc=EDa?=)
Date: Tue Jul 13 08:31:02 2004
Server side widgets
<40F3E961.6010009@toya.net.pl>
Message-ID: <20040713172421.0fab3063.diegocg@teleline.es>
El Tue, 13 Jul 2004 10:06:22 -0400 Sean Middleditch <elanthis@awesomeplay.com> e
scribi?:
> information.
That can also happen for a kernel-based login right? Just do a program which
resembles to the kernel-based login. Windows desktop users don't use the
ctrl+alt+sup combo anyway...they use that "login manager"
Reading a keyboard input and waiting for the user to press enter won't be
allowed inside the kernel (for good reasons) by kernel developers
From Nicolas.Mailhot at laPoste.net Tue Jul 13 08:32:02 2004
From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot)
Date: Tue Jul 13 08:32:45 2004
Server side widgets
In-Reply-To: <Pine.LNX.4.56.0407131806140.1507@gx-112.cs.huji.ac.il>
<40F3E961.6010009@toya.net.pl>
<Pine.LNX.4.56.0407131806140.1507@gx-112.cs.huji.ac.il>
Message-ID: <1089732722.9188.37.camel@ulysse.olympe.o2t>
Le mar, 13/07/2004 ? 18:07 +0300, Ely Levy a ?crit :
> On Tue, 13 Jul 2004, Nicolas Mailhot wrote:
>
> > Le mar, 13/07/2004 ? 10:06 -0400, Sean Middleditch a ?crit :
> >
> > > This is why Windows has the "Push ctrl-alt-delete to login" window on
> > > most corporate workstations. The kernel and _only_ the kernel can catch
> > > and process ctrl-alt-delete.
> >
> > Assuming the link from the keyboard to the computer and from the
> > computer to the screen is safe (which in the brave new wireless world is
> > less and less true)
>
> > A minimalist security feature would probably be for the system to ack
> > local logins with a passphrase the user entered when his account was
> > created. It would not protect against interception but at least you'd
> > know the real system was in the loop somewhere.
>
> And someone would just pick over your shoulder and see it?
Actually I'd be more worried about malware that initiates a connection,
saves the token and replays it later (in this case -> logs ?). If you
have physical access you can usually get most people enter their pass in
slow-mo (suitable for shoulder-peeking) just by jamming one of the keys
they use (for example: caps locks).
Anyway this illustrates my point - without some input hardware help
securing login is a lot of work for very weak assurances.
Cheers,
--
Nicolas Mailhot
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://freedesktop.org/pipermail/xorg/attachments/20040713/cca9fe1c/attach
ment.pgp
From idr at us.ibm.com Tue Jul 13 09:42:07 2004
Date: Tue Jul 13 09:42:44 2004
In-Reply-To: <40F3C508.5090404@nospam.com>
<40F0B7C2.8080500@nospam.com> <1089659889.16003.257.camel@finch.boston
.redhat.com>
<40F3C508.5090404@nospam.com>
Message-ID: <40F410DF.6070109@us.ibm.com>
Andy Sy wrote:
> My main worries are that 2D operations might be klunkier or less
> efficient (considering the horror stories I've heard about the
> performance of glXXXXPixels()) to execute using the OpenGL API.
Basically we have a chicken and egg problem. People are hesitant to use
OpenGL for the windowing system becuase certain parts of it are slow.
Other people are hesitant to make certain parts of OpenGL fast because
they're rarely used. Keep three things in mind:
1. As the windowing system develops, we can make whatever optimizations
are needed in the windowing system or in the open-source 3D drivers to
make things fast.
2. Which paths are fast in a particular vendor's driver is 100% market
driven. If the market starts demanding fast glDrawPixels or fast
convolution filters, the IHVs *will* implement it. They may not do it
right away, but if it will give them a competitive advantage in a given
market, they'll do it.
3. If we get some distance down the path of doing the windowing system
on OpenGL and realize that OpenGL is missing some feature that would
make things faster / easier / better, we can make an extension that
implements that feature. If you're worried about IHVs supporting it,
see point #2. :)
This really *is* a tractable problem. If our only worry is about being
able to use some API to access functionality of the hardware, the only
variable is how much code we want to write to do it.
From idr at us.ibm.com Tue Jul 13 10:00:34 2004
Date: Tue Jul 13 10:01:14 2004
In-Reply-To: <20040713113522.GA8123@hermes.cam.ac.uk>
<40F0B7C2.8080500@nospam.com> <1089659889.16003.257.camel@finch.boston
.redhat.com> <40F3C508.5090404@nospam.com>
<20040713113522.GA8123@hermes.cam.ac.uk>
Message-ID: <40F41532.1090507@us.ibm.com>
Rich Wareham wrote:
> About the only problem I can foresee is that standard OpenGL only
> supports 2**n x 2**n textures although that can be overcome by some
> cunningness (maintain a set of textures and 'stitch' windows together
> from parts of them).
Almost all cards support {NV,EXT,ARB}_texture_rectangle and all next
generation cards should support ARB_texture_non_power_of_two. Two years
ago this would have been a big issue, but it's pretty minor today
(thankfully!). In the open-source drivers, about half the cards are
missing support, but I think about half of those (such as i810, Savaga,
and Unichrome) could do it.
> Of course none of this negates the fact that there are a set of older
> cards which have only 2d acceleration. I guess the question is if people
> want to force users of these to accept software rendered OpenGL or
> whether a sufficient subset of OpenGL can be specified that can be
> implemented on 2D only hardware.
This will be a stinking point, I think. Part of the problem is that
over the past few years the hardware drivers have seen quite a bit of
clever optimization, but software rendering has not. It's a problem
that could be solved with more man-power. I'm not sure if all the
optimization in the world would make it run good on a Pentium 200 and a
ET4000. ;)
The flip side is, of course, that there are even a few 3D capable cards
that don't have 3D support. i740, Permedia2 (and most other 3dlabs
chips), Rendition chips, Trident Cyberblade, and NV3 come to mind.
There may be a few others. Unfortunately, this isn't a purely man-power
solvable problem. We need docs. :(
From alan at lxorguk.ukuu.org.uk Tue Jul 13 10:24:59 2004
Date: Tue Jul 13 11:27:46 2004
Subject: Adding more features or more stability to the next X.org
release ? / was: Re: [Xorg] Next X.Org Foundation release plan
In-Reply-To: <40F34753.FFD8A281@nrubsig.org>
References: <20040709175448.GB18379@kem.org> <40F34753.FFD8A281@nrubsig.org>
On Maw, 2004-07-13 at 03:22, Roland Mainz wrote:
> BTW: This reminds me to say that nearly one third of the platforms which
> should be supported by the Xorg tree in _theory_ do not work: For
> example MacOSX and SCO do not build... and don't even ask about the
> status of the AIX platform.
x86-64 Linux is broken too - it looks for Motif for one app but having
decided you have a motif of some kind hardassumes lib not lib64.
Similarly unichrome was broken but these were all tiny trivial bug
fixes. Are the bugs like AIX / MacOSX trivial things ?
From roland.mainz at nrubsig.org Tue Jul 13 11:44:07 2004
Date: Tue Jul 13 11:44:25 2004
Subject: Adding more features or more stability to the next X.orgrelease ?
/ was: Re: [Xorg] Next X.Org Foundation release plan
Message-ID: <40F42D77.C7294F06@nrubsig.org>
Alan Cox wrote:
>
> On Maw, 2004-07-13 at 03:22, Roland Mainz wrote:
> > BTW: This reminds me to say that nearly one third of the platforms which
> > should be supported by the Xorg tree in _theory_ do not work: For
> > example MacOSX and SCO do not build... and don't even ask about the
> > status of the AIX platform.
>
> x86-64 Linux is broken too
Uhm... I thought I fixed that few days ago... what's wrong now ?
... but Linux/SPARC, Linux/HPPA, OpenVMS are broken ... maybe the next
release should really focus on "... get existing things working on all
supported platforms... " ...
> - it looks for Motif for one app but having
> decided you have a motif of some kind hardassumes lib not lib64.
> Similarly unichrome was broken but these were all tiny trivial bug
> fixes.
>
> Are the bugs like AIX / MacOSX trivial things ?
MacOSX seems to have somewhere problems in OpenGL land, somehow it can't
find |strtok_r| (I can't belive that a _modern_ OS does not have
strok_r() ... but if it is really missing... I wrote the NSPR version
for Mozilla and can donate the same chunk of code to X.org, too :) and
some other problems need to be fixed, too...
AIX status is "unknown", two months ago it didn't build but I do not
have regular access to an AIX box right now. I doubt anything has
changed since then because no checkin referenced "AIX" since then... ;-(
I bet more platforms are horked, but obtaining access to HP-UX, IRIX and
True64 machines is difficult... ;-((
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From krahn at niehs.nih.gov Tue Jul 13 11:48:51 2004
Date: Tue Jul 13 11:49:24 2004
In-Reply-To: <40F41532.1090507@us.ibm.com>
<1089659889.16003.257.camel@finch.boston.redhat.com> <40F3C508.5090404@nospam
.com> <20040713113522.GA8123@hermes.cam.ac.uk>
<40F41532.1090507@us.ibm.com>
Message-ID: <40F42E93.8080407@niehs.nih.gov>
What is the purpose of wanting to use OpenGL as the Window renderer?
Using OpenGL would require that X and OpenGL to render to a
common back buffer, so the two methods of rendering can be used
without conflicts. Maybe this is what OSX does? This would take
some work to get the two synchronized, and maybe not really
possible with closed-source OpenGL drivers.
Otherwise, how can you mix OpenGL rendering and X efficiently?
(Not that I've given it a lot of thought...)
Joe Krahn
Date: Tue Jul 13 11:59:45 2004
In-Reply-To: <40F41532.1090507@us.ibm.com>
<40F3C508.5090404@nospam.com> <20040713113522.GA8123@hermes.cam.ac.uk>
<40F41532.1090507@us.ibm.com>
On Maw, 2004-07-13 at 18:00, Ian Romanick wrote:
> The flip side is, of course, that there are even a few 3D capable cards
> that don't have 3D support. i740, Permedia2 (and most other 3dlabs
> chips), Rendition chips, Trident Cyberblade, and NV3 come to mind.
> There may be a few others. Unfortunately, this isn't a purely man-power
> solvable problem. We need docs. :(
We have cyberblade docs. We have enough info to do a bad older Nvidia
(enough to be useful for 2D use of 3D). We have Cirrus docs, we have
siliconmotion (I think), we have S3.
3DLabs have provided some docs to people in the past so may not be
intractible. i740 might be fun though 8(
As regards performance, (with the exception I'm told of the Nvidia
binary driver) all the XAA drivers suck at reading data back from the
screen already so Mesa wont make it worse.
Date: Tue Jul 13 12:05:21 2004
On Maw, 2004-07-13 at 04:28, Jesse Barnes wrote:
> So, in short, unless there are problems, I'd like to see things like
>
> val = inb(0x3c8)
>
> changed to
>
> iobase = xf86GetLegacyIOBase(Tag);
> ...
> val = inb(iobase + 0x3c8)
>
> *or*
>
> val = inb(Tag, 0x3c8)
To make it work well would it not be better to make
iobase = xf86MapIORange(Tag, size);
for many platforms thats very very efficient to implement. You would
still want explicitly to select the VGA device I suspect though.
Date: Tue Jul 13 12:08:05 2004
Server side widgets
On Maw, 2004-07-13 at 13:03, Jon Smirl wrote:
> The idea of a kernel based login is that it is completely secure and
> can't be trojaned. A key that can't be intercepted is used to trigger
> login. The kernel catches this and clears/draws the screen in a way
> that can't be stopped. The keyboard is then directly read for the login
> data.
The only bit the kernel has to handle is SAK (the key itself)
Date: Tue Jul 13 12:11:19 2004
In-Reply-To: jbarnes@engr.sgi.com wrote on Monday,
12 July 2004 at 06:51:41 -0700
<16626.33905.967271.900052@xf11.fra.suse.de>
>
> In the arch specific in/out routines you mean? I see lots of lines like
> inb(0x3c8) in various drivers and other code...
Can you point me to them, please?
>
> in/out is pretty slow already, and is only used at startup time, afaict. Mos
t
> code just does memory reads/writes to register space doesn't it?
>
This depends very much on the driver.
> >
> > > As it stands, the X server's platform code has to assume one, global,
> > > I/O port base address...
> >
> > Not true any more. Take a look at the AXP and PPC code. Possibly also the
> > IA64 code.
>
> Yeah, I'm looking at the ia64 stuff, it's still missing the necessary support
.
> It looks like ppc is still limited to doing legacy I/O (like the above inb)
> to one bus.
Are you sure? I mean I didn't implement it, but I always had the impression
that the offset values in all the IO code was introduced for that purpose.
I'll take a look later.
Cheers,
Egbert.
Date: Tue Jul 13 12:13:19 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Monday,
12 July 2004 at 09:35:07 -0700
Jon Smirl writes:
>
> We know how to find the BIOS copy in low RAM. What you don't know is
> which card it is associated with in a multiple graphics card system. To
> track this a quirk needs to be added to the kernel which records which
> device is the boot video device. The kernel need to track this since
> device drivers can change the active VGA device and make another device
> look like it was the boot device.
>
It could be done in the kernel or in a daemon that keeps track of the
devices, right. In an environment in which multiple devices can be used
by different applications you cannot use the simple heuristics that
we do today.
Egbert.
Date: Tue Jul 13 12:19:06 2004
Subject: [Xorg] Implementing "Xv" extension on DDX whichdon'tsupportitin
In-Reply-To: roland.mainz@nrubsig.org wrote on Monday,
12 July 2004 at 21:49:23 +0200
<16626.58054.597904.341574@xf11.fra.suse.de>
<40F2EB43.D7EE9D2E@nrubsig.org>
Roland Mainz writes:
>
> Egbert:
> Does that mean that it's valid that a fallback implementation for Xv
> simply converts YUV to RGB and renderes using the PutImage() hook ?
Right.
You can do whatever you want with the video data as long as it ends
up in the right drawable (window) clipped to the visible portions of
the windows enterior.
You will have to do the color transformation and rescaling of the
video data before you ship it to the framebuffer.
I don't expect this to be extremely fast even on rather modern HW, though.
Egbert.
From jbarnes at engr.sgi.com Tue Jul 13 12:18:23 2004
Date: Tue Jul 13 12:19:30 2004
On Tuesday, July 13, 2004 2:02 pm, Alan Cox wrote:
> On Maw, 2004-07-13 at 04:28, Jesse Barnes wrote:
> > So, in short, unless there are problems, I'd like to see things like
> >
> > val = inb(0x3c8)
> >
> > changed to
> >
> > iobase = xf86GetLegacyIOBase(Tag);
> > ...
> > val = inb(iobase + 0x3c8)
> >
> > *or*
> >
> > val = inb(Tag, 0x3c8)
>
> To make it work well would it not be better to make
>
> iobase = xf86MapIORange(Tag, size);
>
> for many platforms thats very very efficient to implement. You would
> still want explicitly to select the VGA device I suspect though.
Sure, that would be even better. For legacy space, size would usually be 64k,
right? Or would we want to add a 'base' argument and allow callers to just
map the ports they're interested in?
Jesse
From hiryu at audioseek.net Tue Jul 13 12:36:08 2004
From: hiryu at audioseek.net (Cameron)
Date: Tue Jul 13 12:24:09 2004
Subject: [Xorg] Error building KDrive
Message-ID: <200407131236.09022.hiryu@audioseek.net>
I get this while running Xserver-inst.sh
It occurs when configure is run in the xserver directory.
There is no xkbfile.pc anywhere on my system Has recetly xkb
been added as a dependency? That would explain it's absence from
Xserver-inst.sh.
mpositeext xkbfile resourceext xdmcp... Package xkbfile was not found in the
pkg-config search path.
Perhaps you should add the directory containing `xkbfile.pc'
to the PKG_CONFIG_PATH environment variable
No package 'xkbfile' found
configure: error: Library requirements (randr render fixesext damageext
xextensions xfont xproto xtrans xau compositeext xkbfile resourceext xdmcp)
not met; consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.
Thanks.
-Cameron
--
"A dream to some... A NIGHTMARE TO OTHERS!"
Date: Tue Jul 13 12:26:46 2004
<16628.13144.707374.160606@xf11.fra.suse.de>
On Tuesday, July 13, 2004 3:09 pm, Egbert Eich wrote:
> Jesse Barnes writes:
> > In the arch specific in/out routines you mean? I see lots of lines like
> > inb(0x3c8) in various drivers and other code...
>
> Can you point me to them, please?
There are too many to list. Just do a 'grep -r inb' in hw/xorg. Many of the
inb calls refer to a base, but in some cases (maybe all cases) the IOBase is
assumed to be global and unique, rather than per-device or per-bus.
> > in/out is pretty slow already, and is only used at startup time, afaict.
> > Most code just does memory reads/writes to register space doesn't it?
>
> This depends very much on the driver.
Right, that's what I was getting at. If there are drivers that use in/out as
their main means of talking to their device, then we'll want to be careful to
keep them fast. Otherwise, performance of those routines isn't very
important.
> Are you sure? I mean I didn't implement it, but I always had the impression
> that the offset values in all the IO code was introduced for that purpose.
Depends on the arch. ppc has a global IObase, ia64 doesn't use one at all,
but I think sparc might be able to deal with multiple base (but like I said
above, I don't think the rest of the code is ready).
> I'll take a look later.
Ok, thanks for looking.
Jesse
Date: Tue Jul 13 12:34:20 2004
> Jon Smirl writes:
> >
> > We know how to find the BIOS copy in low RAM. What you don't know
> is
> > which card it is associated with in a multiple graphics card
> system. To
> > track this a quirk needs to be added to the kernel which records
> which
> > device is the boot video device. The kernel need to track this
> since
> > device drivers can change the active VGA device and make another
> device
> > look like it was the boot device.
> >
>
> It could be done in the kernel or in a daemon that keeps track of the
> devices, right. In an environment in which multiple devices can be
> used
> by different applications you cannot use the simple heuristics that
> we do today.
>
The only safe place to this is in the kernel. It's just a few hundred
bytes of code.
> Egbert.
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Date: Tue Jul 13 12:45:08 2004
On Maw, 2004-07-13 at 20:18, Jesse Barnes wrote:
> Sure, that would be even better. For legacy space, size would usually be 64k,

> right? Or would we want to add a 'base' argument and allow callers to just
> map the ports they're interested in?
For platforms where port space can be bigger than 16bit and when port
space is mmio mapped I can see it helping.
Date: Tue Jul 13 12:47:57 2004
<16628.13144.707374.160606@xf11.fra.suse.de>
On Tuesday, July 13, 2004 3:25 pm, Jesse Barnes wrote:
> On Tuesday, July 13, 2004 3:09 pm, Egbert Eich wrote:
> > Jesse Barnes writes:
> > > In the arch specific in/out routines you mean? I see lots of lines
> > > like inb(0x3c8) in various drivers and other code...
> >
> > Can you point me to them, please?
>
> There are too many to list. Just do a 'grep -r inb' in hw/xorg. Many of
> the inb calls refer to a base, but in some cases (maybe all cases) the
> IOBase is assumed to be global and unique, rather than per-device or
> per-bus.
Actually, now that I've looked at it some more, it's not *that* bad. There
are some places that use absolute values, but many are relative to a base.
Not all platforms support it though, since many declare their in/out routines
to take unsigned short values...
Jesse
Date: Tue Jul 13 12:54:57 2004
side widgets
--- Sean Middleditch <elanthis@awesomeplay.com> wrote:
> > What's wrong with currently available Ctrl-Alt-Backspace? It would
> kill
> > such a malicious session and you will be sure the thing that shows
> up on
> > the screen is same thing somebody with root access have set.
>
> Nope. I can switch to a text console and write a script that
> launches a
> new X session with my fake login program in a loop. kill the X
> server,
> the script just relaunches it. Again, no way to tell if it's my hack
> or
> the real login server.
You need to use special keys that can't be intercepted by an app. An
app can intercept Ctrl-Alt-Backspace and draw a fake login screen. I
believe the only keys that can't be intercepted are Ctrl-Alt-Del and
SysReq. I'm not 100% sure about SysReq.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Tue Jul 13 13:03:12 2004
Server side widgets
On Tue, 2004-07-13 at 15:54, Jon Smirl wrote:
> You need to use special keys that can't be intercepted by an app. An
> app can intercept Ctrl-Alt-Backspace and draw a fake login screen. I
> believe the only keys that can't be intercepted are Ctrl-Alt-Del and
> SysReq. I'm not 100% sure about SysReq.
ctrl-alt-del is currently quite catchable. it's not uncommon to see
desktops with their WM (or other keybinding handler daemon) set to
launch gnome-session-save --kill or something similar. (this is, in
fact, exactly how my machine is setup.) if a kernel-assisted login
system is made, the kernel would also have to be modified to make sure
ctrl-alt-del (or whatever key sequence is chosen) is always only handled
by the kernel.
>
> =====
> Jon Smirl
>
>
>
> __________________________________
> Do you Yahoo!?
--
Date: Tue Jul 13 13:31:22 2004
In-Reply-To: <40F410DF.6070109@us.ibm.com>
--- Ian Romanick <idr@us.ibm.com> wrote:
> This really *is* a tractable problem. If our only worry is about
> being able to use some API to access functionality of the hardware,
> the only variable is how much code we want to write to do it.
This is a map of the ATI X800 chip:
http://graphics.tomshardware.com/graphic/20040504/images/architecture.gif
Note how much of the chip is labeled 2D versus the rest which is
implementing 3D. 2D is not getting any faster, but 3D is getting much
faster each generation. X on OpenGL takes advantage of this hardware
trend.
Cairo has benchmarked 2D drawing on xlib vs glitz/OpenGl (using ATI
proprietary drivers on radeon 9800) as OpenGL being 100 to 1 faster. In
some tests it is 400 to 1. In five years 2D is going to be where VGA is
today.
Also, don't get hung up on a 3D UI. We're not build a 3D UI, we using
the 3D hardware to make a very fast 2D UI. At some point it may do some
3D UI things but that's not the initial goal. Speeding up drawing lets
you do things that weren't possible before like translucency and
complex animations.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Tue Jul 13 13:42:54 2004
side widgets
1.6010009@toya.net.pl> <1089727581.15710.7.camel@support02.civic.twp.ypsilanti.
mi.us> <40F3FE43.2040206@toya.net.pl>
Message-ID: <40F4492B.9040809@toya.net.pl>
>
>>Some random thoughts:
>>
>>What if somebody writes a local exploit? On what systems exposed to such
>>malicious users you allow them to run their own code? (ok... you could
>>possibly mimic the login screen in flash or sth. like that...)
>
> It's impossible to stop users from running code. If nothing else, you
> can manually run ld-so with your binary as input. Other than using
> something like SELinux, which even then (given how sickeningly complex
> it is for even its creators to configure properly on multi-purpose
> machines) will likely have many holes.
So -o noexec is only syntactic sugar?
>>What's wrong with currently available Ctrl-Alt-Backspace? It would kill
>>such a malicious session and you will be sure the thing that shows up on
>>the screen is same thing somebody with root access have set.
>
> Nope. I can switch to a text console and write a script that launches a
> new X session with my fake login program in a loop. kill the X server,
> the script just relaunches it. Again, no way to tell if it's my hack or
> the real login server.
So don't allow running random garbage on different virtual consoles.
Move the whole vt thing to the kernel and allow only root to mess with
it. And make a keybinding to kill everything on a virtual console and
respawn something configured by root. I believe this is the best we can
do about this.
>>Basically we need something to kill everything that is running on the
>>current virtual terminal and respawn whatever there should be - thats a
>>better overall sollution. (it would probably require login managers to
>>be spawned by init and not allocating consoles by themselves, but that
>>could be a good idea anyway)
>
> And then we have a minor security hole in that a user can switch to some
> console another user might be using (but have locked) and kill
> everything running there. (And, before you ask, it is possible to turn
> off the ctrl-alt-backspace to protect against this as well.)
And how does that differ from your proposal? Ctrl-Alt-Del to kill
everything and get a login screen? If we change this to open a new login
screen every time we have a simple DoS attack and if we set some maximum
number of open consoles we get back to the begining (just made a little
more difficult).
>>Of course the problem is nonexistant if we login with some kind of a
>>token (or any other device used only to log in i.e. innaccessible to
>>nonroot programs).
>
> Which is more expensive and difficult to setup than simply installing
> your OS and having it's login system (relatively) secure by default.
> The more difficult it is to secure the machine by the administrator, the
> less likely it is to be secure. Such login devices are already
> available, and high-security networks use them. Login protections like
> we're discussing are more helpful for the average network, where special
> hardware is rare and software protections are about all you'll find. We
> can't make them 100% secure, but we can help them be more secure than
> they were previously.
I know it's not an option for many small sites. It was just a general
remark.
--
Regards,
Jakub Piotr C?apa
Date: Tue Jul 13 13:44:00 2004
In-Reply-To: <200407131236.09022.hiryu@audioseek.net>
References: <200407131236.09022.hiryu@audioseek.net>
Message-ID: <40F4498D.3020308@toya.net.pl>
Cameron wrote:
> I get this while running Xserver-inst.sh
>
> It occurs when configure is run in the xserver directory.
> There is no xkbfile.pc anywhere on my system Has recetly xkb
> been added as a dependency? That would explain it's absence from
> Xserver-inst.sh.
>
> mpositeext xkbfile resourceext xdmcp... Package xkbfile was not found in the
> pkg-config search path.
> Perhaps you should add the directory containing `xkbfile.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'xkbfile' found
>
> configure: error: Library requirements (randr render fixesext damageext
> xextensions xfont xproto xtrans xau compositeext xkbfile resourceext xdmcp)
> not met; consider adjusting the PKG_CONFIG_PATH environment variable if your
> libraries are in a nonstandard prefix so pkg-config can find them.
It's only currently available from xlibs CVS.
http://freedesktop.org/cgi-bin/viewcvs.cgi/xlibs/xkbfile/
--
Regards,
Jakub Piotr C?apa
Date: Tue Jul 13 14:01:05 2004
Subject: Xserver needs to run as "root" on Linux / was:
Re: [Xorg] Server side widgets
In-Reply-To: <40F4492B.9040809@toya.net.pl>
<40F3E961.6010009@toya.net.pl>
<40F3FE43.2040206@toya.net.pl>
<40F4492B.9040809@toya.net.pl>
> > It's impossible to stop users from running code. If nothing else, you
> > can manually run ld-so with your binary as input. Other than using
> > something like SELinux, which even then (given how sickeningly complex
> > it is for even its creators to configure properly on multi-purpose
> > machines) will likely have many holes.
>=20
> So -o noexec is only syntactic sugar?
For the most part. It's deterrent. With noexec, trying to directly
execute a binary (using exec() and such, through the kernel) will be
disabled. There's very many other ways to start a new process from an
arbitrary binary, however.
>=20
> >>What's wrong with currently available Ctrl-Alt-Backspace? It would kill=
=20
> >>such a malicious session and you will be sure the thing that shows up o=
n=20
> >>the screen is same thing somebody with root access have set.
> >=20
> > Nope. I can switch to a text console and write a script that launches =
a
> > new X session with my fake login program in a loop. kill the X server,
> > the script just relaunches it. Again, no way to tell if it's my hack o=
r
> > the real login server.
>=20
> So don't allow running random garbage on different virtual consoles.=20
It's a useful feature. If security axes half the things that we use
Linux/UNIX for, why bother using such an OS at all?
>=20
> >>Basically we need something to kill everything that is running on the=20
> >>current virtual terminal and respawn whatever there should be - thats a=
=20
> >>better overall sollution. (it would probably require login managers to=20
> >>be spawned by init and not allocating consoles by themselves, but that=20
> >>could be a good idea anyway)
> >=20
> > And then we have a minor security hole in that a user can switch to som=
e
> > console another user might be using (but have locked) and kill
> > everything running there. (And, before you ask, it is possible to turn
> > off the ctrl-alt-backspace to protect against this as well.)
>=20
> And how does that differ from your proposal? Ctrl-Alt-Del to kill=20
> everything and get a login screen? If we change this to open a new login=20
When did I say to kill anything? You added the "kill everything" part
on your own. ;-)
> screen every time we have a simple DoS attack and if we set some maximum=20
> number of open consoles we get back to the begining (just made a little=20
> more difficult).
This may be why they are considering putting the login into the kernel
itself (although I believe it's possible to find another solution).=20
With the login in the kernel, the kernel knows that the current VT is
indeed the real login manager, and doesn't need to allocate a new VT.=20
It could also remember which VT already has a login console, and just
switch to that from the current VT when ctrl-alt-del is pressed.
I'm sure it's possible to do this with out-of-kernel processes, but I'm
not a big-time kernel-buff to say for sure. Arguing with me instead of
the people who are actually working on the login system and planning on
bringing it up at the Kernel Summit isn't going to answer that one. ;-)=20
I'd imagine though that it's possible for the kernel to know that it
spawned process X on the VT, and if it's the same process owning the VT,
then it's a safe login console.
I should also note that most systems already allow users to create a
whole bunch of login consoles by using things like gdmflexiserver and
the like. There are a maximum number of VTs, and if you allocate a new
login console on each (assuming login console processes are insane
resource hogs), you can't really DoS the service. It's not like having
three unused login consoles is going to stop someone from logging in.=20
Multiple active logins are actually a good thing. ;-)
--=20
Date: Tue Jul 13 15:03:04 2004
side widgets
1.6010009@toya.net.pl> <1089727581.15710.7.camel@support02.civic.twp.ypsilanti.
mi.us> <40F3FE43.2040206@toya.net.pl> <1089732603.15710.22.camel@support02.civ
ic.twp.ypsilanti.mi.us> <40F4492B.9040809@toya.net.pl>
Message-ID: <40F45C0F.20500@toya.net.pl>
>
>>Sean Middleditch wrote:
>
>>>It's impossible to stop users from running code. If nothing else, you
>>>can manually run ld-so with your binary as input. Other than using
>>>something like SELinux, which even then (given how sickeningly complex
>>>it is for even its creators to configure properly on multi-purpose
>>>machines) will likely have many holes.
>>
>>So -o noexec is only syntactic sugar?
>
> For the most part. It's deterrent. With noexec, trying to directly
> execute a binary (using exec() and such, through the kernel) will be
> disabled. There's very many other ways to start a new process from an
> arbitrary binary, however.
I suspected sth like that when I encountered noexec for the first time
but never actually managed to check myself or google for it. I guess
I've believed that it is somehow made secure and noexec is not only
about making things a little more difficult. ;)
>>>>What's wrong with currently available Ctrl-Alt-Backspace? It would kill
>>>>such a malicious session and you will be sure the thing that shows up on
>>>>the screen is same thing somebody with root access have set.
>>>
>>>Nope. I can switch to a text console and write a script that launches a
>>>new X session with my fake login program in a loop. kill the X server,
>>>the script just relaunches it. Again, no way to tell if it's my hack or
>>>the real login server.
>>
>>So don't allow running random garbage on different virtual consoles.
>
> It's a useful feature. If security axes half the things that we use
> Linux/UNIX for, why bother using such an OS at all?
Not half. What is so useful in being able to spawn a process on a new
vt? (remember - it would be configurable and such strict policies would
only be needed on ~1% of machines, those which can be somehow accessed
by many different and not necessarily trusting each other people)
>>>>Basically we need something to kill everything that is running on the
>>>>current virtual terminal and respawn whatever there should be - thats a
>>>>better overall sollution. (it would probably require login managers to
>>>>be spawned by init and not allocating consoles by themselves, but that
>>>>could be a good idea anyway)
>>>
>>>And then we have a minor security hole in that a user can switch to some
>>>console another user might be using (but have locked) and kill
>>>everything running there. (And, before you ask, it is possible to turn
>>>off the ctrl-alt-backspace to protect against this as well.)
>>
>>And how does that differ from your proposal? Ctrl-Alt-Del to kill
>>everything and get a login screen? If we change this to open a new login
>
> When did I say to kill anything? You added the "kill everything" part
> on your own. ;-)
It was an obvious way to get the real login screen. The other ways of
doing this I thought of were also mentioned but all of them suck IMHO.
So - Yes, I understand the problem and the need of fixing it - No, I
don't really like the proposed solution but I can't find a better one by
myself.
>>screen every time we have a simple DoS attack and if we set some maximum
>>number of open consoles we get back to the begining (just made a little
>>more difficult).
>
> This may be why they are considering putting the login into the kernel
> itself (although I believe it's possible to find another solution).
> With the login in the kernel, the kernel knows that the current VT is
> indeed the real login manager, and doesn't need to allocate a new VT.
> It could also remember which VT already has a login console, and just
> switch to that from the current VT when ctrl-alt-del is pressed.
And what do we do whan we run out of virtual consoles? If somebody logs
in many times and sets a false login screen on every virtual console the
user will just get irritated that TheMagickKeySequence is not working
and enter his password in the first textbox he finds...
> I'm sure it's possible to do this with out-of-kernel processes, but I'm
> not a big-time kernel-buff to say for sure. Arguing with me instead of
> the people who are actually working on the login system and planning on
> bringing it up at the Kernel Summit isn't going to answer that one. ;-)
I don't feel like arguing. I'm rather trying to find a best solution.
(and adding any hardcoded login screen into the kernel is *not* a good
idea in my opinion; ti's the policy-mechanism thing I suppose)
This list is the first place I've encountered this kernel login screen
idea and probably that's why we are discussing it here. ;)
> I'd imagine though that it's possible for the kernel to know that it
> spawned process X on the VT, and if it's the same process owning the VT,
> then it's a safe login console.
>
> I should also note that most systems already allow users to create a
> whole bunch of login consoles by using things like gdmflexiserver and
> the like. There are a maximum number of VTs, and if you allocate a new
> login console on each (assuming login console processes are insane
> resource hogs), you can't really DoS the service. It's not like having
> three unused login consoles is going to stop someone from logging in.
> Multiple active logins are actually a good thing. ;-)
I know. I have two permanent X servers on two vts myself. :) The problem
with vt limit is that the malicious user can take over all of them and
then the magic key won't work anymore.
Two possible solutions:
1. Use the keyboard swithced to a different mode as you would use a
special login device. Make TMKS (TheMagicKeySequence) switch the
keyboard to a special mode in which only uid 0 processes can use it. On
a non login vt the keystrokes would be captured by the parent process
(the one that spawned all user processes - probably the login manager)
and ignored (a warning box could be shown). On a login vt the keystrokes
would be captured by the login program (which must run as root whether
we like it or not).
2. Let TMKS kill the X server running on the vt (or any other process
attached to it) but rewrite GTK and Qt to allow apps to stay alive after
loosing the connection to the X server. Next time the user logs in he
would broadcast a DBUS message to all his running processes with the
info about the new X server he wants them to connect to. Even if not for
solving the login problem, it would rock anyway. Keith Packard (with Jim
Gettys) in "The (Re)Architecture of the X Window System" states that it
ought to be possible and dying upon connection loss is simply a huge and
stupid bug in the toolkits. Of course this is true only if I understood
correctly. ;) However, after reading this text, I feel it is doable and
even not so difficult.
--
Regards,
Jakub Piotr C?apa
Date: Tue Jul 13 15:14:57 2004
Subject: [Xorg] [PATCH] fix configure.ac and Makefile.am to allow x86emu
Daniel, how does this look? It seems to compile ok if I pass --enable-x86emu,
and if I don't pass it, the Makefile is generated like it used to be... If
it looks ok, can you just commit it?
The original Imakefile also set -D__BIG_ENDIAN__, but that should probably be
a global define if it isn't already.
Thanks,
Jesse
-------------- next part --------------
Name: debrix-x86emu-check-2.patch
Type: text/x-diff
Size: 1903 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040713/aab97543/debrix
-x86emu-check-2-0001.bin
Date: Tue Jul 13 15:20:42 2004
References: <E1Bj9wd-0006IW-J9@evo.keithp.com> <40F41532.1090507@us.ibm.com>
Hash: SHA1
On Tuesday 13 July 2004 13:56, Alan Cox wrote:
> On Maw, 2004-07-13 at 18:00, Ian Romanick wrote:
> > The flip side is, of course, that there are even a few 3D capable cards
> > that don't have 3D support. i740, Permedia2 (and most other 3dlabs
> > chips), Rendition chips, Trident Cyberblade, and NV3 come to mind.
> > There may be a few others. Unfortunately, this isn't a purely man-power
> > solvable problem. We need docs. :(
>
> We have cyberblade docs. We have enough info to do a bad older Nvidia
> (enough to be useful for 2D use of 3D). We have Cirrus docs, we have
> siliconmotion (I think), we have S3.
Yes, we have SMI docs, there's links on the DRI wiki. And there's still an nv
driver sitting in UtahGLX that needs to get ported to DRI.
> 3DLabs have provided some docs to people in the past so may not be
> intractible. i740 might be fun though 8(
I looked into i740 a few days ago. The datasheets for the 740 and 810 are
extremely similar, and comparing the feature lists, the 740 appears to be the
810 without multitexturing and a few texture formats. There was also a
brief-lived i752 chip - which you could get on an AGP card like the 740 -
which appears to be identical to the 810 graphics controller (i've seen 810
chipsets that claim to have a 752 graphics controller on eBay). So they're
probably more similar than Intel lets on.
The register locations aren't the same, and there may be some other bugs that
don't show up in the public 740 docs, but I strongly suspect a 740 DRI driver
could be done from the public 810 docs. It's no Radeon but it's probably
faster than software Mesa for a few more iterations of Moore's Law.
- - ajax
iD8DBQFA9GAmW4otUKDs0NMRAmzFAJ9XWTe8n5RP7SPF7DNorEE/FAgvawCeOF6S
bRAqg0ZKti/qwUm+/e6yrLo=
=7uEP
From krh at bitplanet.net Tue Jul 13 16:38:51 2004
Date: Tue Jul 13 16:40:36 2004
References: <200407131814.10421.jbarnes@engr.sgi.com>
Message-ID: <40F4728B.7040305@bitplanet.net>
Shouldn't that be enabled by default? I've been trying to run the i830
driver and it doesn't get far with just stub.c...
Kristian
Jesse Barnes wrote:
> Daniel, how does this look? It seems to compile ok if I pass --enable-x86emu,

> and if I don't pass it, the Makefile is generated like it used to be... If
> it looks ok, can you just commit it?
>
> The original Imakefile also set -D__BIG_ENDIAN__, but that should probably be
> a global define if it isn't already.
>
> Thanks,
> Jesse
>
>
> ------------------------------------------------------------------------
>
> Index: configure.ac
> ===================================================================
> RCS file: /cvs/xserver/debrix/configure.ac,v
> retrieving revision 1.7
> diff -u -r1.7 configure.ac
> --- configure.ac 6 Jul 2004 23:53:56 -0000 1.7
> +++ configure.ac 13 Jul 2004 22:13:10 -0000
> @@ -106,6 +106,7 @@
> AC_ARG_ENABLE(glx, [ --enable-glx ],[GLX=$enableval],[GLX=no])
> AC_ARG_ENABLE(dri, [ --enable-dri ],[DRI=$enableval],[DRI=no])
> AC_ARG_ENABLE(xinerama, [ --disable-xinerama ],[XINERAMA=$enableva
l],[XINERAMA=yes])
> +AC_ARG_ENABLE(x86emu, AS_HELP_STRING([--enable-x86emu],[use x86 e
mulator for int10 library (default: disabled)]),[X86EMU=$enableval],[X86EMU=no])
>
> # Transport selection
> AC_ARG_ENABLE(unix-transport,[ --disable-unix-transport ], [UNIXCONN=$enable
val], [UNIXCONN=yes])
> @@ -215,6 +216,8 @@
> REQUIRED_MODULES="$REQUIRED_MODULES panoramixext"
> fi
>
> +AM_CONDITIONAL(X86EMU, [test x$X86EMU = xyes])
> +
> AM_CONDITIONAL(XLOADABLE, [test x$XLOADABLE = xyes])
> if test "$XLOADABLE" = yes; then
> AC_DEFINE(XLOADABLE,1,[Support loadable input and output drivers])
> Index: hw/xorg/int10/Makefile.am
> ===================================================================
> RCS file: /cvs/xserver/debrix/hw/xorg/int10/Makefile.am,v
> diff -u -r1.4 Makefile.am
> --- hw/xorg/int10/Makefile.am 1 Jul 2004 17:49:48 -0000 1.4
> +++ hw/xorg/int10/Makefile.am 13 Jul 2004 22:13:10 -0000
> @@ -2,9 +2,13 @@
>
> #ibxorgint10_a_SOURCES = stub.c
>
> -libint10_a_SOURCES = stub.c xf86int10module.c
> -
> -# FIXME: i386/amd64-only (and Linux-only!!)
> +if X86EMU
> +AM_CFLAGS = -D_X86EMU -D__DRIVER__ -DFORCE_POST -D_CEXPORT= -DNO_LONG_LONG
> +libint10_a_SOURCES = pci.c xf86int10module.c helper_exec.c helper_mem.c \
> + xf86int10.c xf86x86emu.c generic.c x86emu.c
> +else
> AM_CFLAGS = -D_PC -D_VM86_LINUX
> +libint10_a_SOURCES = stub.c xf86int10module.c
> +endif
>
> sdk_HEADERS = xf86int10.h
From hiryu at audioseek.net Tue Jul 13 16:57:52 2004
From: hiryu at audioseek.net (Cameron)
Date: Tue Jul 13 16:45:27 2004
In-Reply-To: <40F4498D.3020308@toya.net.pl>
References: <200407131236.09022.hiryu@audioseek.net>
<40F4498D.3020308@toya.net.pl>
Message-ID: <200407131657.52823.hiryu@audioseek.net>
Thanks,
I added the necessary stuff to the script to download and compile xkbfile for
me and now it builds.
-Cameron
On Tuesday 13 July 2004 1:43 pm, Jakub Piotr C?apa wrote:
> Cameron wrote:
> > I get this while running Xserver-inst.sh
> >
> > It occurs when configure is run in the xserver directory.
> > There is no xkbfile.pc anywhere on my system Has recetly xkb
> > been added as a dependency? That would explain it's absence from
> > Xserver-inst.sh.
> >
> > mpositeext xkbfile resourceext xdmcp... Package xkbfile was not found in
> > the pkg-config search path.
> > Perhaps you should add the directory containing `xkbfile.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'xkbfile' found
> >
> > configure: error: Library requirements (randr render fixesext damageext
> > xextensions xfont xproto xtrans xau compositeext xkbfile resourceext
> > xdmcp) not met; consider adjusting the PKG_CONFIG_PATH environment
> > variable if your libraries are in a nonstandard prefix so pkg-config can
> > find them.
>
> It's only currently available from xlibs CVS.
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xlibs/xkbfile/
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From k.healy at mars.ucc.ie Tue Jul 13 17:01:15 2004
From: k.healy at mars.ucc.ie (Ken Healy)
Date: Tue Jul 13 17:01:20 2004
Subject: [Xorg] How should a driver hook into the X server's idle loop
Message-ID: <40F41981@webmail.ucc.ie>
Quick summary. (See below for context and details).
How can an X device driver hook in to the X server's idle loop to process
asynchronous requests (e.g. read a command from a file descriptor and act on
it, when flagged by a SIGIO handler).
-----------------------
(I'm new to X driver and linux kernel coding, so if I say anything incorrect,
please point it out.
Also apologies for the poor terminology. Its hard to phrase questions when
you're only beginning to learn the lingo).
I'm working on extending the video/tv sections of the GATOS driver to fully
support video4linux(2). (See http://gatos.sf.net for more info on GATOS, it
provides 3D accel and video/tv-in support for Radeon, All In Wonder and older
ATI cards).
This presents what seems to be an unusual challenge, in the context of the
current graphics and video implementations in X + linux.
This comes down to the fact that the graphics and tv-in hardware are together
on the same card, whereas in software, the graphics driver is in the Xserver,
and the tv-in driver (at least the v4l one) is in the kernel.
Given that I'm not going to be rewriting the X driver architecture, or
video4linux, then my driver is going to have kernel-side and Xserver-side
parts, and an interface between them. Also, most of the communication on this
interface will be initiated on the kernel-side - this seems to be unusual too
(is it?).
I see as much of the hardware specifics as possible staying on the Xserver
side (the notable exception being DMA).
So commands on the interface will be, for example, set_tuner_frequency,
set_input_source, set_brightness, get_signal_strength etc.
I have a idea of how I am going to implement this interface, but there are
still some blanks to fill in.
I'd really appreciate any comments, suggestions or advice on the outline
below.
The kernel module will create a /proc or sysfs file for the i/o, which the X
driver will open with FASYNC set, for async notification.
The X driver also installs a corresponding SIGIO handler to pickup to
notifications.
Now, I am pretty sure its a bad idea to do any significant processing in a
SIGIO handler (although I haven't found any docs on that). So I think the
handler should just set a flag or post an event telling the driver there's a
command waiting to be read.
Here's where the blanks are.
How can a driver hook in to the Xserver's idle loop to check for flags or
events, and then run the relevant commands?
Is it ok to use a simple flag? Or is it possible to define private events, and
have the driver hook in to the event loop to receive them?
Is this a good way to implement an interface like this? Is there a better way?
Pointers to relevant documentation, and existing driver, extension code that
would make good examples, would also be greatly appreciated.
(I've seen the docs in xc/doc and xc/programs/Xserver/hw/xfree86/doc)
Regards,
Ken.
Date: Tue Jul 13 17:14:52 2004
side widgets
In-Reply-To: <40F45C0F.20500@toya.net.pl>
Another thing to consider is that the entire VT system could be removed
from the kernel and pushed into user space. Doing that will change how
you implement the login screen.
There are two classes of output:
printk, system boot, kdbg, ie kernel things
everything else
kernel things need to be displayed from inside the kernel
everything else can be displayed from user space
Which group is the login screen in?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From erikharrison at gmail.com Tue Jul 13 17:17:37 2004
Date: Tue Jul 13 17:18:10 2004
Server side widgets
<40F3E961.6010009@toya.net.pl>
Message-ID: <5b18a542040713171747cc3695@mail.gmail.com>
On Tue, 13 Jul 2004 10:06:22 -0400, Sean Middleditch
<elanthis@awesomeplay.com> wrote:
> > Jon Smirl wrote:
>
> > > The idea of a kernel based login is that it is completely secure and
> > > can't be trojaned. A key that can't be intercepted is used to trigger
> > > login. The kernel catches this and clears/draws the screen in a way
> > > that can't be stopped. The keyboard is then directly read for the login
> > > data.
> >
> > Looks really Windowish (and fishy) to me...
> >
> > Why is this better than x/g/w/xdm? AFAIR from the beggining Unixes used
>
> information.
>
>
> guarantee that you are at the real login screen; kernel-level checks
> using a kernel-only key sequence is one way to do this. Perhaps the
> kernel can, upon receiving the key-combination, open a new VT and launch
> a specific binary (GDM/KDM/etc) on it? The only way to trojan that
> would be to over-write the login manager binaries or somehow get access
> to control a VT owned by root/login-manager-user, which shouldn't be any
> easier than cracking the kernel login system, no?
This seems like the kind of thing the ditro vendors should hadnle.
CTRL+ALT+DEL generates a keyboard events only trappable by the kernel.
The kernel can have what action it performs on this event be
customized - for example, hitting ctrl+alt+del opens a login screen.
Bada bing, no need to put login/*dm in the kernel.
-Erik
>
> > (min)getty+login for logging in on text terminals and it works without
> > problems (I can event change mingetty to fbgetty to get some fancy
> > graphic into the framebuffer).
> > What make graphic consoles different?
>
> Nothing. The security problem is there with mingetty as well. The same
> system discussed here could potentially be used to alleviate that
> problem as well.
>
> --
>
>
>
>
> _______________________________________________
> xorg mailing list
>
Date: Tue Jul 13 17:24:04 2004
References: <E1Bj9wd-0006IW-J9@evo.keithp.com> <40F41532.1090507@us.ibm.com>
<200407131820.28094.ajax@nwnk.net>
On Maw, 2004-07-13 at 23:20, Adam Jackson wrote:
> > We have cyberblade docs. We have enough info to do a bad older Nvidia
> > (enough to be useful for 2D use of 3D). We have Cirrus docs, we have
> > siliconmotion (I think), we have S3.
>
> Yes, we have SMI docs, there's links on the DRI wiki. And there's still an nv

> driver sitting in UtahGLX that needs to get ported to DRI.
Yep. I'm still working on debugging the 6326 port - I've got what look
like garbage co-ordinates although I suspect in the changes to vertex
buffer handling I've simply screwed the vertex stuff up in the port.
I'm still hopeful that a combination of that code, the sis kernel module
and some clear docs on which few pieces to swap will give us a basis for
a "fill in the blanks" driver for the dumb end of the graphics market -
which will matter for 2D using 3D X. These early cards are all much
alike to some level - textures in frame buffer or sometimes AGP space,
similar management needs, no DMA queues instead you what registers each
triangle.
Date: Tue Jul 13 17:32:59 2004
side widgets
Message-ID: <40F47F39.40002@toya.net.pl>
Jon Smirl wrote:
> Another thing to consider is that the entire VT system could be removed
> from the kernel and pushed into user space. Doing that will change how
> you implement the login screen.
>
> There are two classes of output:
> printk, system boot, kdbg, ie kernel things
> everything else
>
> kernel things need to be displayed from inside the kernel
> everything else can be displayed from user space
>
> Which group is the login screen in?
IMO the login screen itself belongs to the userspace but it shouldn't
really matter for its security. We would only need kernel providing a
way to switch the keyboard to a special mode in which the keystrokes
could be captured only by priviledged programs.
Maybe this also could be done in userspace? I know nothing about how is
the low-level keyboard access done on Linux. ;/
Whole vt management could probably as well run as root in userspace.
Probably EOT - I gave some ideas but I don't (yet) know enough to get
down to the low-level implementation details...
--
Regards,
Jakub Piotr C?apa
Date: Tue Jul 13 17:34:25 2004
Subject: [Xorg] How should a driver hook into the X server's idle loop
In-Reply-To: <40F41981@webmail.ucc.ie>
References: <40F41981@webmail.ucc.ie>
On Mer, 2004-07-14 at 01:01, Ken Healy wrote:
> Quick summary. (See below for context and details).
>
> How can an X device driver hook in to the X server's idle loop to process
> asynchronous requests (e.g. read a command from a file descriptor and act on
> it, when flagged by a SIGIO handler).
There are some worked examples in the input layer, including masking the
SIGIO handler.
Take a look at AddEnabledDevice(fd), RemoveEnabledDevice(fd) and friends
From qbast at go2.pl Tue Jul 13 20:49:48 2004
Date: Tue Jul 13 20:49:01 2004
In-Reply-To: <40F4728B.7040305@bitplanet.net>
<40F4728B.7040305@bitplanet.net>
Dnia ?ro 14. lipca 2004 01:38, Kristian H?gsberg napisa?:
> Shouldn't that be enabled by default? I've been trying to run the i830
> driver and it doesn't get far with just stub.c...
On Linux you can use vm86 handler from os-specific/linux/int10 instead. It
seems to work better (and in my opinion should be default for Linux/i386) -
allows to get DDC information from monitor on Toshiba Satellite Pro 4600 with
Trident CyberBlade/XP (x86emu fails with "01 illegal extended opcode").
>
> Kristian
>
> Jesse Barnes wrote:
> > Daniel, how does this look? It seems to compile ok if I pass
> > --enable-x86emu, and if I don't pass it, the Makefile is generated like
> > it used to be... If it looks ok, can you just commit it?
> >
> > The original Imakefile also set -D__BIG_ENDIAN__, but that should
> > probably be a global define if it isn't already.
> >
> > Thanks,
> > Jesse
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index: configure.ac
> > ===================================================================
> > RCS file: /cvs/xserver/debrix/configure.ac,v
> > retrieving revision 1.7
> > diff -u -r1.7 configure.ac
> > --- configure.ac 6 Jul 2004 23:53:56 -0000 1.7
> > +++ configure.ac 13 Jul 2004 22:13:10 -0000
> > @@ -106,6 +106,7 @@
> > AC_ARG_ENABLE(glx, [ --enable-glx
> > ],[GLX=$enableval],[GLX=no]) AC_ARG_ENABLE(dri, [ --enable-dri
> > ],[DRI=$enableval],[DRI=no]) AC_ARG_ENABLE(xinerama, [
> > --disable-xinerama ],[XINERAMA=$enableval],[XINERAMA=yes])
> > +AC_ARG_ENABLE(x86emu, AS_HELP_STRING([--enable-x86emu],[use x86
> > emulator for int10 library (default:
> > disabled)]),[X86EMU=$enableval],[X86EMU=no])
> >
> > # Transport selection
> > AC_ARG_ENABLE(unix-transport,[ --disable-unix-transport ],
> > [UNIXCONN=$enableval], [UNIXCONN=yes]) @@ -215,6 +216,8 @@
> > REQUIRED_MODULES="$REQUIRED_MODULES panoramixext"
> > fi
> >
> > +AM_CONDITIONAL(X86EMU, [test x$X86EMU = xyes])
> > +
> > AM_CONDITIONAL(XLOADABLE, [test x$XLOADABLE = xyes])
> > if test "$XLOADABLE" = yes; then
> > AC_DEFINE(XLOADABLE,1,[Support loadable input and output drivers])
> > Index: hw/xorg/int10/Makefile.am
> > ===================================================================
> > RCS file: /cvs/xserver/debrix/hw/xorg/int10/Makefile.am,v
> > diff -u -r1.4 Makefile.am
> > --- hw/xorg/int10/Makefile.am 1 Jul 2004 17:49:48 -0000 1.4
> > +++ hw/xorg/int10/Makefile.am 13 Jul 2004 22:13:10 -0000
> > @@ -2,9 +2,13 @@
> >
> > #ibxorgint10_a_SOURCES = stub.c
> >
> > -libint10_a_SOURCES = stub.c xf86int10module.c
> > -
> > -# FIXME: i386/amd64-only (and Linux-only!!)
> > +if X86EMU
> > +AM_CFLAGS = -D_X86EMU -D__DRIVER__ -DFORCE_POST -D_CEXPORT=
> > -DNO_LONG_LONG +libint10_a_SOURCES = pci.c xf86int10module.c
> > helper_exec.c helper_mem.c \ + xf86int10.c xf86x86emu.c generic.c
> > x86emu.c
> > +else
> > AM_CFLAGS = -D_PC -D_VM86_LINUX
> > +libint10_a_SOURCES = stub.c xf86int10module.c
> > +endif
> >
> > sdk_HEADERS = xf86int10.h
>
> _______________________________________________
> xorg mailing list
Date: Tue Jul 13 21:26:33 2004
Does it work if you apply the patch and enable it?
Jesse
On Tuesday, July 13, 2004 7:38 pm, Kristian H?gsberg wrote:
> Shouldn't that be enabled by default? I've been trying to run the i830
> driver and it doesn't get far with just stub.c...
>
> Kristian
>
> Jesse Barnes wrote:
> > Daniel, how does this look? It seems to compile ok if I pass
> > --enable-x86emu, and if I don't pass it, the Makefile is generated like
> > it used to be... If it looks ok, can you just commit it?
> >
> > The original Imakefile also set -D__BIG_ENDIAN__, but that should
> > probably be a global define if it isn't already.
> >
> > Thanks,
> > Jesse
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index: configure.ac
> > ===================================================================
> > RCS file: /cvs/xserver/debrix/configure.ac,v
> > diff -u -r1.7 configure.ac
> > --- configure.ac 6 Jul 2004 23:53:56 -0000 1.7
> > +++ configure.ac 13 Jul 2004 22:13:10 -0000
> > @@ -106,6 +106,7 @@
> > AC_ARG_ENABLE(glx, [ --enable-glx
> > ],[GLX=$enableval],[GLX=no]) AC_ARG_ENABLE(dri, [ --enable-dri
> > ],[DRI=$enableval],[DRI=no]) AC_ARG_ENABLE(xinerama, [
> > --disable-xinerama ],[XINERAMA=$enableval],[XINERAMA=yes])
> > +AC_ARG_ENABLE(x86emu, AS_HELP_STRING([--enable-x86emu],[use x86
> > emulator for int10 library (default:
> > disabled)]),[X86EMU=$enableval],[X86EMU=no])
> >
> > # Transport selection
> > AC_ARG_ENABLE(unix-transport,[ --disable-unix-transport ],
> > [UNIXCONN=$enableval], [UNIXCONN=yes]) @@ -215,6 +216,8 @@
> > REQUIRED_MODULES="$REQUIRED_MODULES panoramixext"
> > fi
> >
> > +AM_CONDITIONAL(X86EMU, [test x$X86EMU = xyes])
> > +
> > AM_CONDITIONAL(XLOADABLE, [test x$XLOADABLE = xyes])
> > if test "$XLOADABLE" = yes; then
> > AC_DEFINE(XLOADABLE,1,[Support loadable input and output drivers])
> > Index: hw/xorg/int10/Makefile.am
> > ===================================================================
> > RCS file: /cvs/xserver/debrix/hw/xorg/int10/Makefile.am,v
> > diff -u -r1.4 Makefile.am
> > --- hw/xorg/int10/Makefile.am 1 Jul 2004 17:49:48 -0000 1.4
> > +++ hw/xorg/int10/Makefile.am 13 Jul 2004 22:13:10 -0000
> > @@ -2,9 +2,13 @@
> >
> > #ibxorgint10_a_SOURCES = stub.c
> >
> > -libint10_a_SOURCES = stub.c xf86int10module.c
> > -
> > -# FIXME: i386/amd64-only (and Linux-only!!)
> > +if X86EMU
> > +AM_CFLAGS = -D_X86EMU -D__DRIVER__ -DFORCE_POST -D_CEXPORT=
> > -DNO_LONG_LONG +libint10_a_SOURCES = pci.c xf86int10module.c
> > helper_exec.c helper_mem.c \ + xf86int10.c xf86x86emu.c generic.c
> > x86emu.c
> > +else
> > AM_CFLAGS = -D_PC -D_VM86_LINUX
> > +libint10_a_SOURCES = stub.c xf86int10module.c
> > +endif
> >
> > sdk_HEADERS = xf86int10.h
From lars at trolltech.com Wed Jul 14 01:07:56 2004
From: lars at trolltech.com (Lars Knoll)
Date: Wed Jul 14 01:01:38 2004
Message-ID: <200407141007.56953.lars@trolltech.com>
On Tuesday 13 July 2004 22:31, Jon Smirl wrote:
> --- Ian Romanick <idr@us.ibm.com> wrote:
> > This really *is* a tractable problem. If our only worry is about
> > being able to use some API to access functionality of the hardware,
> > the only variable is how much code we want to write to do it.
>
> This is a map of the ATI X800 chip:
> http://graphics.tomshardware.com/graphic/20040504/images/architecture.gif
>
> Note how much of the chip is labeled 2D versus the rest which is
> implementing 3D. 2D is not getting any faster, but 3D is getting much
> faster each generation. X on OpenGL takes advantage of this hardware
> trend.
>
> Cairo has benchmarked 2D drawing on xlib vs glitz/OpenGl (using ATI
> proprietary drivers on radeon 9800) as OpenGL being 100 to 1 faster. In
> some tests it is 400 to 1. In five years 2D is going to be where VGA is
> today.
Actually we've done the same now for Qt 4 (having a possibility to issue the
same 2d painting commands with regular X or on a open GL widget). The openGL
code renders our example at least a factor of 50-100 faster on all X servers
that have hardware openGL support.
Another reason I see is that there is lots of work going on to implement and
imrpove open GL support for different hardware, while there is almost no work
done on the 2d front. After more than 2 years with RENDER, there are still
almost no X drivers that implement hardware acceleration for simple things as
rendering a pixmap with an alpha channel. And since Xft, this is one of the
more common operations the server has to perform.
Best regards,
Lars
> Also, don't get hung up on a 3D UI. We're not build a 3D UI, we using
> the 3D hardware to make a very fast 2D UI. At some point it may do some
> 3D UI things but that's not the initial goal. Speeding up drawing lets
> you do things that weren't possible before like translucency and
> complex animations.
>
> =====
> Jon Smirl
>
>
>
> __________________________________
> Do you Yahoo!?
>
> _______________________________________________
> xorg mailing list
Date: Wed Jul 14 01:39:50 2004
In-Reply-To: <40F42E93.8080407@niehs.nih.gov>
<40F3C508.5090404@nospam.com> <20040713113522.GA8123@hermes.cam.ac.uk>
<40F41532.1090507@us.ibm.com> <40F42E93.8080407@niehs.nih.gov>
On Tue, 2004-07-13 at 14:48 -0400, Joe Krahn wrote:
> What is the purpose of wanting to use OpenGL as the Window renderer?
>
> Using OpenGL would require that X and OpenGL to render to a
> common back buffer, so the two methods of rendering can be used
> without conflicts. Maybe this is what OSX does? This would take
> some work to get the two synchronized, and maybe not really
> possible with closed-source OpenGL drivers.
>
> Otherwise, how can you mix OpenGL rendering and X efficiently?
That's a problem now, because the X server and GLX clients don't use the
same rendering mechanism. The idea is for the X server to use OpenGL for
all of its rendering as well.
--
Date: Wed Jul 14 01:49:49 2004
Subject: Adding more features or more stability to the next X.orgrelease
? / was: Re: [Xorg] Next X.Org Foundation release plan
In-Reply-To: <40F42D77.C7294F06@nrubsig.org>
<40F42D77.C7294F06@nrubsig.org>
On Tue, 13 Jul 2004, Roland Mainz wrote:
> Alan Cox wrote:
> >
> > Are the bugs like AIX / MacOSX trivial things ?
>
> MacOSX seems to have somewhere problems in OpenGL land,
There have been changes to the visual configuration in the glx structures.
I've fixed this for cygwin by copying the code from the indirect mesa code.
bye
ago
--
Date: Wed Jul 14 03:20:51 2004
Subject: [Xorg] Re: [PATCH] fix configure.ac and Makefile.am to allow x86emu
Message-ID: <20040714102048.GH15281@fooishbar.org>
On Tue, Jul 13, 2004 at 06:14:10PM -0400, Jesse Barnes wrote:
> Daniel, how does this look? It seems to compile ok if I pass --enable-x86emu,

> and if I don't pass it, the Makefile is generated like it used to be... If
> it looks ok, can you just commit it?
>
> The original Imakefile also set -D__BIG_ENDIAN__, but that should probably be
> a global define if it isn't already.
Great, thanks; looks fine to me. I'll drag it into my tla repo in the
next couple of days, when I get some time.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040714/3f0b50e2/attach
ment.pgp
From sndirsch at suse.de Wed Jul 14 06:19:25 2004
Date: Wed Jul 14 06:19:32 2004
In-Reply-To: <20040712132339.GA27480@suse.de>
References: <20040712132339.GA27480@suse.de>
On Mon, Jul 12, 2004 at 03:23:39PM +0200, Stefan Dirsch wrote:
> I just updated to current CVS and recognized that the (binary-only)
> nvidia driver for Linux no longer works with that version. Error
> messages are:
>
> Symbol vgaHWGetIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o i
s unresolved!
> Symbol vgaHWSave from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is un
resolved!
> Symbol vgaHWRestore from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
> Symbol vgaHWUnmapMem from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o i
s unresolved!
> Symbol fbCloseScreen from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o i
s unresolved!
> Symbol fbWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv
.o is unresolved!
> Symbol fbCreateWindow from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> Symbol fbCreateGC from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is u
nresolved!
> Symbol fbGCPrivateIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv.
o is unresolved!
> Symbol fbValidateGC from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
> Symbol fbPictureInit from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o i
s unresolved!
>
> *** If unresolved symbols were reported above, they might not
> *** be the reason for the server aborting.
>
> Fatal server error:
> Caught signal 11. Server aborting
>
> I verified that the nvidia driver still works with CVS of 04-06-27,
> but is at least broken with CVS of 04-07-07 and later. Simply using
> the Xorg binary of 04-06-27 fixes the problem.
>
> Anyone who is able to reproduce this?
Looks like it can be reproduced.
======================================================================
From: dave ! <ag051379@hotmail.com>
To: sndirsch@suse.de
Subject: Re: [Xorg] nvidia driver no longer works with current CVS?
Date: Wed, 14 Jul 2004 21:08:22 +1000
Hi
I built xorg CVS this past weekend and got the same error's trying to
use nvidia's driver. I'm not signed up for the mailing-list but feel
free to forward this email there.
======================================================================
> Any ideas which radical changes might be responsible for this?
Stefan
----------------------------------------------------
FAX: 0911-740 53 479 D-90409 N?rnberg
----------------------------------------------------
From krh at bitplanet.net Wed Jul 14 06:22:19 2004
Date: Wed Jul 14 06:24:03 2004
Message-ID: <40F5338B.60001@bitplanet.net>
Yes, I have the i830 driver running, but there were other problems:
since libvbe.a and libfb.a are linked into the Xorg binary at link time,
the linker throws aways .o files from the .a file that aren't used by
the server binary, e.g.
[krh@dinky debrix]$ nm Xorg |grep fbPi
0812b650 T fbPixmapToRegion
no fbPictureInit, but maybe I'm doing something wrong? This happens to
vbeModes.o and fbpict.o so I added dummy references to symbols in those
files to get them linked in. I810VideoInit() segfaults, but I disabled
that for now and then it works.
Kristian
Jesse Barnes wrote:
> Does it work if you apply the patch and enable it?
>
> Jesse
>
> On Tuesday, July 13, 2004 7:38 pm, Kristian H?gsberg wrote:
>
>>Shouldn't that be enabled by default? I've been trying to run the i830
>>driver and it doesn't get far with just stub.c...
>>
>>Kristian
>>
>>Jesse Barnes wrote:
>>
>>>Daniel, how does this look? It seems to compile ok if I pass
>>>--enable-x86emu, and if I don't pass it, the Makefile is generated like
>>>it used to be... If it looks ok, can you just commit it?
>>>
>>>The original Imakefile also set -D__BIG_ENDIAN__, but that should
>>>probably be a global define if it isn't already.
>>>
>>>Thanks,
>>>Jesse
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>Index: configure.ac
>>>===================================================================
>>>RCS file: /cvs/xserver/debrix/configure.ac,v
>>>retrieving revision 1.7
>>>diff -u -r1.7 configure.ac
>>>--- configure.ac 6 Jul 2004 23:53:56 -0000 1.7
>>>+++ configure.ac 13 Jul 2004 22:13:10 -0000
>>>@@ -106,6 +106,7 @@
>>> AC_ARG_ENABLE(glx, [ --enable-glx
>>>],[GLX=$enableval],[GLX=no]) AC_ARG_ENABLE(dri, [ --enable-dri
>>>],[DRI=$enableval],[DRI=no]) AC_ARG_ENABLE(xinerama, [
>>>--disable-xinerama ],[XINERAMA=$enableval],[XINERAMA=yes])
>>>+AC_ARG_ENABLE(x86emu, AS_HELP_STRING([--enable-x86emu],[use x86
>>>emulator for int10 library (default:
>>>disabled)]),[X86EMU=$enableval],[X86EMU=no])
>>>
>>> # Transport selection
>>> AC_ARG_ENABLE(unix-transport,[ --disable-unix-transport ],
>>>[UNIXCONN=$enableval], [UNIXCONN=yes]) @@ -215,6 +216,8 @@
>>> REQUIRED_MODULES="$REQUIRED_MODULES panoramixext"
>>> fi
>>>
>>>+AM_CONDITIONAL(X86EMU, [test x$X86EMU = xyes])
>>>+
>>> AM_CONDITIONAL(XLOADABLE, [test x$XLOADABLE = xyes])
>>> if test "$XLOADABLE" = yes; then
>>> AC_DEFINE(XLOADABLE,1,[Support loadable input and output drivers])
>>>Index: hw/xorg/int10/Makefile.am
>>>===================================================================
>>>RCS file: /cvs/xserver/debrix/hw/xorg/int10/Makefile.am,v
>>>retrieving revision 1.4
>>>diff -u -r1.4 Makefile.am
>>>--- hw/xorg/int10/Makefile.am 1 Jul 2004 17:49:48 -0000 1.4
>>>+++ hw/xorg/int10/Makefile.am 13 Jul 2004 22:13:10 -0000
>>>@@ -2,9 +2,13 @@
>>>
>>> #ibxorgint10_a_SOURCES = stub.c
>>>
>>>-libint10_a_SOURCES = stub.c xf86int10module.c
>>>-
>>>-# FIXME: i386/amd64-only (and Linux-only!!)
>>>+if X86EMU
>>>+AM_CFLAGS = -D_X86EMU -D__DRIVER__ -DFORCE_POST -D_CEXPORT=
>>>-DNO_LONG_LONG +libint10_a_SOURCES = pci.c xf86int10module.c
>>>helper_exec.c helper_mem.c \ + xf86int10.c xf86x86emu.c generic.c
>>>x86emu.c
>>>+else
>>> AM_CFLAGS = -D_PC -D_VM86_LINUX
>>>+libint10_a_SOURCES = stub.c xf86int10module.c
>>>+endif
>>>
>>> sdk_HEADERS = xf86int10.h
>
>
>
Date: Wed Jul 14 06:41:39 2004
References: <200407131814.10421.jbarnes@engr.sgi.com> <40F4728B.7040305@bitpla
net.net> <200407140025.14594.jbarnes@engr.sgi.com>
Message-ID: <40F5380F.4080605@toya.net.pl>
Kristian H?gsberg wrote:
> Yes, I have the i830 driver running, but there were other problems:
> since libvbe.a and libfb.a are linked into the Xorg binary at link time,
> the linker throws aways .o files from the .a file that aren't used by
> the server binary, e.g.
>
> [krh@dinky debrix]$ nm Xorg |grep fbPi
> 0812b650 T fbPixmapToRegion
>
> no fbPictureInit, but maybe I'm doing something wrong? This happens to
> vbeModes.o and fbpict.o so I added dummy references to symbols in those
> files to get them linked in. I810VideoInit() segfaults, but I disabled
> that for now and then it works.
I posted a patch for this here. Look in the archives. The explanation of
how is the symbol garbage collection working can also be found there.
--
Regards,
Jakub Piotr C?apa
From sandmann at daimi.au.dk Wed Jul 14 06:50:28 2004
Date: Wed Jul 14 06:50:36 2004
Subject: [Xorg] Re: Faster render with gcc 3.4 mmx intrinsics
In-Reply-To: <ye87jtewhza.fsf@ec02.daimi.au.dk>
Message-ID: <ye87jt6k89n.fsf@horse04.daimi.au.dk>
> On bug 839
>
>
> there is a patch adding faster versions of some the render ops.
Unless someone speaks up, I'll commit the speedups on Friday.
S?ren
From rjw57 at hermes.cam.ac.uk Wed Jul 14 07:01:01 2004
From: rjw57 at hermes.cam.ac.uk (Rich Wareham)
Date: Wed Jul 14 06:57:17 2004
Subject: [Xorg] Patch to fix build error
Message-ID: <20040714140101.GA6401@hermes.cam.ac.uk>
Something like the following needs to be done to allow xserver to
finish configure-ing with the --enable-xorgserver option set on my
system. Its not the 'correct' solution but someone needs to look at
howmany / where the backslashes go.
diff -u -r3.86 configure.ac
--- configure.ac 7 Jul 2004 19:21:06 -0000 3.86
+++ configure.ac 14 Jul 2004 13:53:55 -0000
@@ -464,12 +464,7 @@
XORG_INCS=
XORG_OS=
if test "$XORGSERVER" = yes; then
- XORG_INC='-I$(top_srcdir)/hw/xorg/include \\\
- -I$(top_srcdir)/hw/xorg/common \\\
- -I$(top_srcdir)/hw/xorg/os-support \\\
- -I$(top_srcdir)/include \\\
- -I$(top_srcdir)/os \\\
- -I$(top_srcdir)/hw/xorg/os-support/bus'
+ XORG_INC='-I$(top_srcdir)/hw/xorg/include -I$(top_srcdir)/hw/xorg/common
-I$(top_srcdir)/hw/xorg/os-support -I$(top_srcdir)/include -I$(top_srcdir)/os -
I$(top_srcdir)/hw/xorg/os-support/bus'
XORG_CORE_LIBS="$DIX_LIB"
XORG_LIBS="$FB_LIB $MI_LIB $XI_LIB $XKB_LIB $EXTENSION_LIBS \
$DAMAGE_LIB $SHADOW_LIB $XPSTUBS_LIB $OS_LIB"
--
Rich
From sndirsch at suse.de Wed Jul 14 07:41:51 2004
Date: Wed Jul 14 07:41:54 2004
In-Reply-To: <20040714131925.GA5572@suse.de>
References: <20040712132339.GA27480@suse.de> <20040714131925.GA5572@suse.de>
Hi
I made a bugreport for this. Bug #868.
Stefan
On Wed, Jul 14, 2004 at 03:19:25PM +0200, Stefan Dirsch wrote:
> On Mon, Jul 12, 2004 at 03:23:39PM +0200, Stefan Dirsch wrote:
> > I just updated to current CVS and recognized that the (binary-only)
> > nvidia driver for Linux no longer works with that version. Error
> > messages are:
> >
> > Symbol vgaHWGetIndex from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> > Symbol vgaHWSave from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
> > Symbol vgaHWRestore from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> > Symbol vgaHWUnmapMem from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> > Symbol fbCloseScreen from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> > Symbol fbWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/nvidia_d
rv.o is unresolved!
> > Symbol fbCreateWindow from module /usr/X11R6/lib/modules/drivers/nvidia_drv.
o is unresolved!
> > Symbol fbCreateGC from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o is
unresolved!
> > Symbol fbGCPrivateIndex from module /usr/X11R6/lib/modules/drivers/nvidia_dr
v.o is unresolved!
> > Symbol fbValidateGC from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> > Symbol fbPictureInit from module /usr/X11R6/lib/modules/drivers/nvidia_drv.o
is unresolved!
> >
> > *** If unresolved symbols were reported above, they might not
> > *** be the reason for the server aborting.
> >
> > Fatal server error:
> > Caught signal 11. Server aborting
> >
> > I verified that the nvidia driver still works with CVS of 04-06-27,
> > but is at least broken with CVS of 04-07-07 and later. Simply using
> > the Xorg binary of 04-06-27 fixes the problem.
> >
> > Anyone who is able to reproduce this?
>
> Looks like it can be reproduced.
>
> ======================================================================
> From: dave ! <ag051379@hotmail.com>
> To: sndirsch@suse.de
> Subject: Re: [Xorg] nvidia driver no longer works with current CVS?
> Date: Wed, 14 Jul 2004 21:08:22 +1000
>
> Hi
>
> I built xorg CVS this past weekend and got the same error's trying to
> use nvidia's driver. I'm not signed up for the mailing-list but feel
> free to forward this email there.
> ======================================================================
>
> > Any ideas which radical changes might be responsible for this?
----------------------------------------------------
FAX: 0911-740 53 479 D-90409 N?rnberg
----------------------------------------------------
Date: Wed Jul 14 08:38:36 2004
<40F4728B.7040305@bitplanet.net> <200407140549.48517.qbast@go2.pl>
On Tuesday, July 13, 2004 11:49 pm, Jakub Stachowski wrote:
> Dnia ?ro 14. lipca 2004 01:38, Kristian H?gsberg napisa?:
> > Shouldn't that be enabled by default? I've been trying to run the i830
> > driver and it doesn't get far with just stub.c...
>
> On Linux you can use vm86 handler from os-specific/linux/int10 instead. It
> seems to work better (and in my opinion should be default for Linux/i386) -
> allows to get DDC information from monitor on Toshiba Satellite Pro 4600
> with Trident CyberBlade/XP (x86emu fails with "01 illegal extended
> opcode").
Hm, it seems like x86emu should work on any platform, but I'm not familiar
enough with its internals to say whether you need more defines for x86.
Unconditionally enabling it would give us more exposure on the emulator and
remove some special cases, so that's probably worth considering (assuming we
can fix the problem you're seeing). Otherwise, we'll probably want an
autodetection function that uses vm86 on x86 and x86-64, but uses the
emulator for every other platform.
Jesse
From ralpht at gmail.com Wed Jul 14 08:45:12 2004
From: ralpht at gmail.com (Ralph Thomas)
Date: Wed Jul 14 08:45:22 2004
Server side widgets
In-Reply-To: <40F47F39.40002@toya.net.pl>
<40F47F39.40002@toya.net.pl>
Message-ID: <72fed370040714084570c33668@mail.gmail.com>
I don't claim to know anything about OS security, but that's not going
to stop me from openly opining :).
You could just have two different device files for each keyboard, call
them "/dev/keyboard" and "/dev/keyboard-special".
On "/dev/keyboard-special" you could have two new ioctls defined:
- "Exclusive" means that keypresses ONLY get reported by
"/dev/keyboard-special"
- "NonExclusive" means that keypresses get reported by
"/dev/keyboard" and "/dev/keyboard-special" (and through any other
means that keypresses get reported)
Then you could have some daemon listen to "/dev/keyboard-special" for
ctrl+alt+delete or whatever and then issue the "Exclusive" ioctl and
do it's secret password and username stuff - once it had done that it
could issue the "NonExclusive" ioctl.
The security comes when you have an ability to restrict access to
"/dev/keyboard-special", either by file permissions or some more
elaborate SELinux setup.
--ralpht
On Wed, 14 Jul 2004 02:32:57 +0200, Jakub Piotr C?apa <loc@toya.net.pl> wrote:
> Jon Smirl wrote:
> > Another thing to consider is that the entire VT system could be removed
> > from the kernel and pushed into user space. Doing that will change how
> > you implement the login screen.
> >
> > There are two classes of output:
> > printk, system boot, kdbg, ie kernel things
> > everything else
> >
> > kernel things need to be displayed from inside the kernel
> > everything else can be displayed from user space
> >
> > Which group is the login screen in?
>
> IMO the login screen itself belongs to the userspace but it shouldn't
> really matter for its security. We would only need kernel providing a
> way to switch the keyboard to a special mode in which the keystrokes
> could be captured only by priviledged programs.
> Maybe this also could be done in userspace? I know nothing about how is
> the low-level keyboard access done on Linux. ;/
>
> Whole vt management could probably as well run as root in userspace.
>
> Probably EOT - I gave some ideas but I don't (yet) know enough to get
> down to the low-level implementation details...
>
> --
> Regards,
> Jakub Piotr C?apa
>
Date: Wed Jul 14 08:48:53 2004
In-Reply-To: <40F5380F.4080605@toya.net.pl>
References: <200407131814.10421.jbarnes@engr.sgi.com> <40F4728B.7040305@bitpla
net.net> <200407140025.14594.jbarnes@engr.sgi.com> <40F5338B.60001@
bitplanet.net>
<40F5380F.4080605@toya.net.pl>
Message-ID: <40F55580.6080707@bitplanet.net>
> Kristian H?gsberg wrote:
>
>> Yes, I have the i830 driver running, but there were other problems:
>> since libvbe.a and libfb.a are linked into the Xorg binary at link
>> time, the linker throws aways .o files from the .a file that aren't
>> used by the server binary, e.g.
>>
>> [krh@dinky debrix]$ nm Xorg |grep fbPi
>> 0812b650 T fbPixmapToRegion
>>
>> no fbPictureInit, but maybe I'm doing something wrong? This happens to
>> vbeModes.o and fbpict.o so I added dummy references to symbols in
>> those files to get them linked in. I810VideoInit() segfaults, but I
>> disabled that for now and then it works.
>
>
> I posted a patch for this here. Look in the archives. The explanation of
> how is the symbol garbage collection working can also be found there.
It's just the difference between linking against libvbe.a vs. linking
against the object files directly. When you link against an archive,
the linker only includes those .o files that contain symbols referenced
by the application. This is why it's enough to only reference one
symbol from each file to get it linked in. On the other hand, if you
list the object files explicitly on the link command line all the object
files are added to the application, wether or not they are used.
Anyway, to get i830 going I added fbPictureInit and VBEGetModePool to
xf86sym.c:
--- orig/hw/xorg/loader/xf86sym.c
+++ mod/hw/xorg/loader/xf86sym.c
@@ -1216,5 +1216,9 @@
/* shadowfb */
SYMFUNC(ShadowFBInit)
+ /* KRH: Hack to pull in symbol defined in otherwise unused .o files */
+ SYMFUNC(VBEGetModePool)
+ SYMFUNC(fbPictureInit)
+
{0, 0}
};
Kristian
From seb at hypercubesystems.co.uk Wed Jul 14 09:12:57 2004
From: seb at hypercubesystems.co.uk (Seb James)
Date: Wed Jul 14 09:13:03 2004
Subject: [Xorg] unresolved symbols in cross compiled Xorg
Message-ID: <1089821577.3747.46.camel@circle.hypercube>
Hello,

I'm building X for a small x86 device. It's a cross-compiled build for a
Linux/uclibc system, built on an i686 Linux host. Having built Xorg
successfully, I'm having problems at runtime with symbols in some of the
Xorg modules; specifically, libxaa.a, libfb.a and libramdac.a.
I'll concentrate on libxaa, as I think if I can fix this one it'll point
me in the right direction for the others.
>From the Xorg log:
----
Skipping "/usr/X11R6/lib/modules/libxaa.a:xaaBitOrder.o": No symbols found
Skipping "/usr/X11R6/lib/modules/libxaa.a:xaaTables.o": No symbols found
----
Then I get a lot of output like this before Xorg quits:
----
Symbol byte_expand3 from module /usr/X11R6/lib/modules/libxaa.a is unresolved!
Symbol byte_reversed_expand3 from module /usr/X11R6/lib/modules/libxaa.a is unre
solved!
----
However, nm shows that there _are_ symbols in both xaaTables.o,
xaaBitOrder.o and libxaa.a:
$i686-linux-uclibc-nm xaaBitOrder.o
00000000 T XAAReverseBitOrder
$i686-linux-uclibc-nm xaaTables.o
00000000 D byte_expand3
00000400 D byte_reversed_expand3
$i686-linux-uclibc-nm libxaa.a | grep byte
00000000 D byte_expand3
00000400 D byte_reversed_expand3
U byte_expand3
U byte_expand3
U byte_reversed_expand3
U byte_expand3
U byte_expand3
U byte_reversed_expand3
or does it?
Why are these symbols apparently existent in libxaa.a, but not
recognized by Xorg when it loads libxaa?
What condition causes Xorg to skip a section in a module library?
Thanks in advance for any answers.
Seb James
--
Sebastian James - Embedded Systems.
Hypercube Systems Ltd 'Embedded Linux Solutions'
35 Walkley Crescent Road, Sheffield, S6 5BA
Tel: 0845 4580277 Web: www.hypercubesystems.co.uk
Date: Wed Jul 14 09:16:33 2004
On Mer, 2004-07-14 at 16:37, Jesse Barnes wrote:
> Hm, it seems like x86emu should work on any platform, but I'm not familiar
> enough with its internals to say whether you need more defines for x86.
> Unconditionally enabling it would give us more exposure on the emulator and
> remove some special cases, so that's probably worth considering (assuming we
> can fix the problem you're seeing). Otherwise, we'll probably want an
> autodetection function that uses vm86 on x86 and x86-64, but uses the
> emulator for every other platform.
In the longer term it might also be worth switching to a better
emulator. The Qemu core is much much faster and also more accurate in
its emulation functions - eg it can run the C&T 655xx BIOS while x86emu
fails to do this. The core is LGPL however so I'm not sure how well that
fits Xorg policy.
Date: Wed Jul 14 09:22:31 2004
Server side widgets
In-Reply-To: <72fed370040714084570c33668@mail.gmail.com>
<40F47F39.40002@toya.net.pl>
<72fed370040714084570c33668@mail.gmail.com>
On Mer, 2004-07-14 at 16:45, Ralph Thomas wrote:
> Then you could have some daemon listen to "/dev/keyboard-special" for
> ctrl+alt+delete or whatever and then issue the "Exclusive" ioctl and
> do it's secret password and username stuff - once it had done that it
> could issue the "NonExclusive" ioctl.
The current approach is actually simpler. If you enable SAK then when
SAK is hit every process connected to that console is disconnected from
it and generally dies. Init then spawns a new getty.
The only area this breaks down is with X because if you just kill off X
bad stuff occurs right now. Once the mode handling support is in the
kernel then when X dies the fb layer either directly or via a user mode
helper run from hotplug will sort the mess out.
Date: Wed Jul 14 10:15:10 2004
side widgets
<40F47F39.40002@toya.net.pl>
Message-ID: <40F56567.50802@toya.net.pl>
Alan Cox wrote:
> On Mer, 2004-07-14 at 16:45, Ralph Thomas wrote:
>
>>Then you could have some daemon listen to "/dev/keyboard-special" for
>>ctrl+alt+delete or whatever and then issue the "Exclusive" ioctl and
>>do it's secret password and username stuff - once it had done that it
>>could issue the "NonExclusive" ioctl.
>
> The current approach is actually simpler. If you enable SAK then when
> SAK is hit every process connected to that console is disconnected from
> it and generally dies. Init then spawns a new getty.
>
> The only area this breaks down is with X because if you just kill off X
> bad stuff occurs right now. Once the mode handling support is in the
> kernel then when X dies the fb layer either directly or via a user mode
> helper run from hotplug will sort the mess out.
But there is a problem with a mallicious user killing a logged in session.
The exclusive keyboard would allow us to configure programs used for
logging in (mingetty, xdm) and make sure no other processes can capture
passwords. It seems secure to me and definitely more flexible than any
builtin kernel login demons.
--
Regards,
Jakub Piotr C?apa
Date: Wed Jul 14 10:46:03 2004
Subject: [Xorg] Kernel Summit and console design
I see that keithp is running the KS session about video drivers. It
might be useful to hash this out with the X developers since a lot of
people at Kernel Summit don't work with graphics cards. Many of these
things have been discussed on this an other lists before.
First is a basic assumption, there are two kinds of display output from
the system:
1) kernel stuff - printk, kernel boot, kdbg, OOPS. Kernel stuff can
have a high display priority and optionally override other displays,
for example a kernel OOPS while you are running X. Since the system
just crashed getting that OOPS on the screen is the most important
thing in the system. Kernel display can not use userspace code since
user space may be dead.
2) everything else
Now working from this assumption, the video driver must have a kernel
entry point for drawing to the screen. This entry point has to be
optionally able to force itself onto the screen.
Next there are a bunch of discussion points about how to build
everything else...
1) SAK - how to achive a guaranteed secure login that can't be trojaned
2) multiuser support - supporting multiple cards and different users
logged into each head, both at the console level and X level
3) after looking at multiuser you will want to move the VT system to
user space, how can this be done?
4) should there be a standard IOCTL interface to video drivers, or
should the IOCTL interface to drivers be private and the published API
be a library API?
5) If an OOPS needs to interrupt X, how can it draw? Should the OOPS
attempt to change the display mode, or should the OOPS code be general
enough to clear and draw the display without changing the mode?
6) What about an OOPS during an uninterruptable graphics operation?
should the kernel drivers force the complete atomic operation to be
submitted to the kernel before starting the operation in order to
guarantee that it can be finished if user space is dead?
7) should there be a single device driver for each card or should the
kernel implement a robust system for multitasking different drivers
onto the hardware
8) kernel drawing does not need acceleration. If the VT system and user
consoles are running from user space could they use a user space
library for acceleration instead of the existing fbdev model?
9) what should the driver IOCTL interface look like? fbdev, DRI,
something new?
10) Should user space hardware access from things like X be blocked?
Instead a 2D XAA driver would be moved to an external library and X
would call this library. The library would be granted hardware access.
The point of the external library is to allow coordinated access to it
from non-X apps like user console and user space VT implementations.
Hardware access would be blocked from all apps, not just X. Everyone
would have to use the library.
11) what is the future of VGA mode? how will it be controlled with
multiple cards are present?
12) How is mode setting handled? Is everything done in the kernel?
Everything in user space? How about computing the register values
needed for achieving the valid modes in user space and the storing the
values in the driver. If you use a KVM switch you need to recompute.
13) How do secondary cards get reset in a multicard system?
14) How are we going to get all the groups working together and
building a coordinated system?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Wed Jul 14 11:14:07 2004
In-Reply-To: <40F56567.50802@toya.net.pl>
<40F47F39.40002@toya.net.pl>
<40F56567.50802@toya.net.pl>
On Mer, 2004-07-14 at 17:55, Jakub Piotr C?apa wrote:
> But there is a problem with a mallicious user killing a logged in session.
>
> The exclusive keyboard would allow us to configure programs used for
> logging in (mingetty, xdm) and make sure no other processes can capture
> passwords. It seems secure to me and definitely more flexible than any
> builtin kernel login demons.
You also have to know that the "mingetty" you are looking at is the real
thing. Thats one thing SAK solves definitively. With regards to
killing sessions, SAK is assuming console access so the user is also
typically capable of removing the power, putting an axe through the
monitor and a number of other hard to defend techniques for killing
logged in sessions.
Date: Wed Jul 14 11:44:56 2004
In-Reply-To: <40F55580.6080707@bitplanet.net>
<40F5338B.60001@bitplanet.net> <40F5380F.4080605@toya.net.pl>
<40F55580.6080707@bitplanet.net>
On Wed, Jul 14, 2004 at 05:47:12PM +0200, Kristian H??gsberg wrote:
> Jakub Piotr C??apa wrote:
> >Kristian H??gsberg wrote:
> >>Yes, I have the i830 driver running, but there were other problems:
> >>since libvbe.a and libfb.a are linked into the Xorg binary at link
> >>time, the linker throws aways .o files from the .a file that aren't
> >>used by the server binary, e.g.
> >>
> >>[krh@dinky debrix]$ nm Xorg |grep fbPi
> >>0812b650 T fbPixmapToRegion
> >>
> >>no fbPictureInit, but maybe I'm doing something wrong? This happens to
> >>vbeModes.o and fbpict.o so I added dummy references to symbols in
> >>those files to get them linked in. I810VideoInit() segfaults, but I
> >>disabled that for now and then it works.
> >
> >
> >I posted a patch for this here. Look in the archives. The explanation of
> >how is the symbol garbage collection working can also be found there.
>
> It's just the difference between linking against libvbe.a vs. linking
> against the object files directly. When you link against an archive,
> the linker only includes those .o files that contain symbols referenced
> by the application. This is why it's enough to only reference one
> symbol from each file to get it linked in. On the other hand, if you
> list the object files explicitly on the link command line all the object
> files are added to the application, wether or not they are used.
>
> Anyway, to get i830 going I added fbPictureInit and VBEGetModePool to
> xf86sym.c:
>
> --- orig/hw/xorg/loader/xf86sym.c
> +++ mod/hw/xorg/loader/xf86sym.c
> @@ -1216,5 +1216,9 @@
> /* shadowfb */
> SYMFUNC(ShadowFBInit)
>
> + /* KRH: Hack to pull in symbol defined in otherwise unused .o files */
> + SYMFUNC(VBEGetModePool)
> + SYMFUNC(fbPictureInit)
> +
> {0, 0}
> };
Thanks - merged as
daniel@fooishbar.org--2004/debrix--devel--0.1--patch--4.
For instructions on getting my archive via arch, please see
http://debrix.freedesktop.org - I intend to have a CVS mirror up soon.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040715/2f5368ca/attach
ment.pgp
Date: Wed Jul 14 11:45:15 2004
In-Reply-To: <20040714181401.GN15281@fooishbar.org>
<20040714181401.GN15281@fooishbar.org>
Message-ID: <40F579FE.6080004@bitplanet.net>
Daniel Stone wrote:
...
> Thanks - merged as
> daniel@fooishbar.org--2004/debrix--devel--0.1--patch--4.
>
> For instructions on getting my archive via arch, please see
> http://debrix.freedesktop.org - I intend to have a CVS mirror up soon.
I've imported the i810 driver from cvs into
krh@bitplanet.net--projects/debrix-driver-i810--krh--0.1 at
http://bitplanet.net/arch/2004. If you set up a
debrix-driver-i810--devel--0.1 version you could just tag it from my
archive.
Btw something's up with your server again:
[krh@dinky xscope]$ tla abrowse daniel@fooishbar.org--2004-SOURCE
webdav error: 404 Not Found
Kristian
From elanthis at awesomeplay.com Wed Jul 14 11:31:12 2004
Date: Wed Jul 14 11:47:32 2004
<40F47F39.40002@toya.net.pl>
<40F56567.50802@toya.net.pl>
On Wed, 2004-07-14 at 12:18, Alan Cox wrote:
> On Mer, 2004-07-14 at 17:55, Jakub Piotr C=C5=82apa wrote:
> > But there is a problem with a mallicious user killing a logged in sessi=
on.
> >=20
> > The exclusive keyboard would allow us to configure programs used for=20
> > logging in (mingetty, xdm) and make sure no other processes can capture=
=20
> > passwords. It seems secure to me and definitely more flexible than any=20
> > builtin kernel login demons.
>=20
> You also have to know that the "mingetty" you are looking at is the real
> thing. Thats one thing SAK solves definitively. With regards to
> killing sessions, SAK is assuming console access so the user is also
> typically capable of removing the power, putting an axe through the
> monitor and a number of other hard to defend techniques for killing
> logged in sessions.
a) if you're going to assume that kind of stuff, why not assume they
have access to the hard-disk and can just modify the password database
using external means?
b) it's quite easy to have a local-login on a physically secure
computer. we have a couple machines here that are locked up in the
counters. users could destroy the monitor and periphials, but those
won't kill sessions (and thus lose or, much worse, corrupt, data) as
they can be replaced while the machine is running.
c) what about remote logins anyway? surely any secure login system,
whether the login is actually in-kernel or trusted user-space system,
would be capable of doing full PAM-style authentication. I could see a
dumb terminal use a locally safe login system to authenticate to a
remote XDMCP server and initiate a session. even if the local terminal
is destroyed, other remote client protocols are session-aware and won't
just kill the application processes on disconnection, but instead wait
for reconnection from the same or another terminal.
I really do think that easy killing of sessions is bad news. It _can_
cause corrupt data in a lot of unfortunately non-super-safe applications
(ones which don't write and modify data in a virtually atomic way).
--=20
Date: Wed Jul 14 11:54:37 2004
In-Reply-To: <40F579FE.6080004@bitplanet.net>
<20040714181401.GN15281@fooishbar.org>
<40F579FE.6080004@bitplanet.net>
Message-ID: <20040714185435.GO15281@fooishbar.org>
> >Thanks - merged as
> >daniel@fooishbar.org--2004/debrix--devel--0.1--patch--4.
> >
> >For instructions on getting my archive via arch, please see
> >http://debrix.freedesktop.org - I intend to have a CVS mirror up soon.
>
> I've imported the i810 driver from cvs into
> krh@bitplanet.net--projects/debrix-driver-i810--krh--0.1 at
> http://bitplanet.net/arch/2004. If you set up a
> debrix-driver-i810--devel--0.1 version you could just tag it from my
> archive.
Done, mirrored.
> Btw something's up with your server again:
>
> [krh@dinky xscope]$ tla abrowse daniel@fooishbar.org--2004-SOURCE
> webdav error: 404 Not Found
I changed the archive location yesterday, so you have to change it:
tla register-archive -f daniel@fooishbar.org--2004-SOURCE http://arch.fooishbar.
org/daniel@fooishbar.org--2004
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040715/6bb4a3c4/attach
ment.pgp
Date: Wed Jul 14 12:10:55 2004
In-Reply-To: <20040714185435.GO15281@fooishbar.org>
<20040714181401.GN15281@fooishbar.org>
<20040714185435.GO15281@fooishbar.org>
Message-ID: <40F584D3.3070000@bitplanet.net>
Daniel Stone wrote:
> On Wed, Jul 14, 2004 at 08:22:54PM +0200, Kristian H??gsberg wrote:
>
>>Daniel Stone wrote:
>>
>>>Thanks - merged as
>>>daniel@fooishbar.org--2004/debrix--devel--0.1--patch--4.
>>>
>>>For instructions on getting my archive via arch, please see
>>>http://debrix.freedesktop.org - I intend to have a CVS mirror up soon.
>>
>>I've imported the i810 driver from cvs into
>>krh@bitplanet.net--projects/debrix-driver-i810--krh--0.1 at
>>http://bitplanet.net/arch/2004. If you set up a
>>debrix-driver-i810--devel--0.1 version you could just tag it from my
>>archive.
>
>
> Done, mirrored.
>
>
>>Btw something's up with your server again:
>>
>>[krh@dinky xscope]$ tla abrowse daniel@fooishbar.org--2004-SOURCE
>>webdav error: 404 Not Found
>
>
> I changed the archive location yesterday, so you have to change it:
> tla register-archive -f daniel@fooishbar.org--2004-SOURCE http://arch.fooishba
r.org/daniel@fooishbar.org--2004
That's what I use:
wget http://arch.fooishbar.org/daniel@fooishbar.org--2004/.listing
...
HTTP request sent, awaiting response... 404 Not Found
Kristian
Date: Wed Jul 14 12:11:12 2004
side widgets
<40F47F39.40002@toya.net.pl>
<40F56567.50802@toya.net.pl>
Message-ID: <40F5854E.4000003@toya.net.pl>
Alan Cox wrote:
> On Mer, 2004-07-14 at 17:55, Jakub Piotr C?apa wrote:
>
>>But there is a problem with a mallicious user killing a logged in session.
>>
>>The exclusive keyboard would allow us to configure programs used for
>>logging in (mingetty, xdm) and make sure no other processes can capture
>>passwords. It seems secure to me and definitely more flexible than any
>>builtin kernel login demons.
>
> You also have to know that the "mingetty" you are looking at is the real
> thing.
If it is not it won't receive any keypresses in the special mode.
> Thats one thing SAK solves definitively. With regards to
> killing sessions, SAK is assuming console access so the user is also
> typically capable of removing the power, putting an axe through the
> monitor and a number of other hard to defend techniques for killing
> logged in sessions.
It is possible to secure the hardware. We are not talking about typical
cases, because these are mostly single-user, private installations.
--
Regards,
Jakub Piotr C?apa
Date: Wed Jul 14 12:19:01 2004
In-Reply-To: <40F584D3.3070000@bitplanet.net>
<20040714181401.GN15281@fooishbar.org>
<20040714185435.GO15281@fooishbar.org>
<40F584D3.3070000@bitplanet.net>
Message-ID: <20040714191858.GP15281@fooishbar.org>
> >>Btw something's up with your server again:
> >>
> >>[krh@dinky xscope]$ tla abrowse daniel@fooishbar.org--2004-SOURCE
> >>webdav error: 404 Not Found
> >
> >
> >I changed the archive location yesterday, so you have to change it:
> >tla register-archive -f daniel@fooishbar.org--2004-SOURCE
> >http://arch.fooishbar.org/daniel@fooishbar.org--2004
>
> That's what I use:
>
> wget http://arch.fooishbar.org/daniel@fooishbar.org--2004/.listing
> ...
> HTTP request sent, awaiting response... 404 Not Found
Yah, you need to use WebDAV instead. Strange that it failed; a couple of
people on #freedesktop reported they could mirror OK. I'll check it out
in an hour or so.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040715/4c767304/attach
ment.pgp
Date: Wed Jul 14 14:04:48 2004
<200407100744.32179.ajax@nwnk.net> <40EFE261.6040006@toya.net.pl>
<200407100842.33294.ajax@nwnk.net>
Message-ID: <40F59F5C.7000409@bitplanet.net>
Adam Jackson wrote:
> Hash: SHA1
>
>
>>
>>>On Saturday 10 July 2004 06:42, Jakub Piotr C?apa wrote:
>>>
>>>>Also I have some minor visial glitches with xfwm4 in the corners of the
>>
>> ^^^^^
>>
>>>>windows. Would you like a screenshot? ;)
>>>
>>>Only if the workaround in
>>>http://freedesktop.org/bugzilla/show_bug.cgi?id=756 doesn't fix it...
>>
>>Your screenshot doesn't look like a showcase of a minor glitch to me. :D
>
>
> Didn't you know the whole point of bugzilla was to take astonishingly worrying

> screenshots? ;)
>
>
>>No. This option doesn't change anything (look at the corners of the
>>windows):
>>https://mimiru.one.pl/~jpc/images/debrix-gcmd.png
>>https://mimiru.one.pl/~jpc/images/xorg-gcmd.png
>
>
> Dang. I think we got a partially munged XAA when we branched. Any chance one

> of the other XAA options is the culprit?
I think it's missing the SHAPE extension. I get similar but slightly
different artifacts for the round corners, and a lot of
Xlib: extension "SHAPE" missing on display ":1.0".
Kristian
Date: Wed Jul 14 16:09:02 2004
Subject: [Xorg] Debrix #include policy
Hi guys,
I've been doing battle royale with the monolithic tree for a while now,
and have been immensely frustated by the inconsistency of #includes. So,
for debrix, I *will* *not* *accept* patches that do not have
exported/whatever includes in #include <X11/foo.h> form. This goes for
all subdirectories as well - <X11/extensions/foo.h>, <X11/fonts/foo.h>,
whatever. There are a couple of these throughout the drivers; I'll fix
them up later on this week.
Fair warning,
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040715/14fe6277/attach
ment.pgp
Date: Wed Jul 14 16:41:44 2004
In-Reply-To: <40F1756A.80103@bitplanet.net>
References: <20040709175448.GB18379@kem.org> <40F1756A.80103@bitplanet.net>
Message-ID: <40F5C44F.7020405@bitplanet.net>
Kristian H?gsberg wrote:
> Kevin E Martin wrote:
>
>> On today's release wranglers call, the group discussed plans for having
>> the next X.Org Foundation release by August 25th. The primary new
>> features planned for this release are three new extensions: Damage,
>> XFixes and Composite.
>>
>> Some of the open questions are:
>>
>> - What is the state of each of these extensions, and what additional
>> work is needed to complete their integration into the CVS repository?
>> - What other functionality should be integrated before the release?
>> - Is the DRI support up-to-date or are there additional bug fixes that
>> need to be applied to the tree?
>> - What other patches/bug fixes are needed?
>
>
> I sent a patch to remove legacy keyboard support in favour of the new,
> modularized kbd keyboard driver. Egbert suggested that the way to go
> with this was to deprecate the legacy driver and not compile it by
> default for a while. After that the legacy driver could hopefully be
> removed. Would it be appropriate to take this firste step with the next
> release? The release after that could then remove the legacy driver.
Another point: when we move to debrix, with everything modularized, it
would be nice to be able to factor out the input drivers completely.
The new driver allows this, but the old driver is tangled up with and
hardcoded into the initialization sequence and can not be separated from
the core server.
I think it would make good sense if we could drop the legacy driver when
the modular release goes out. Until then, here's a patch to disable
building the legacy driver by default, and print a big fat warning in
the case that somebody does anyway.
Kristian
-------------- next part --------------
Name: deprecate-old-keyboard.patch
Type: text/x-patch
Size: 5187 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040715/5c3135ea/deprec
ate-old-keyboard.bin
Date: Wed Jul 14 21:19:38 2004
References: <40F105D7.5010003@toya.net.pl>
Message-ID: <40F5F774.F787CA09@nrubsig.org>
>
> I've made an autotooling patch [1] for libXp. It's not ideal, probably
> the automake autoadded files are just plain wrong but it works. :)
>
> Before you ask: xprint (from mozdev.org) does not provide any libs.
Yup, the old Xprint tree (which means: The new repository for Xprint is
now cvs.freedesktop.org:/cvs/xorg itself, the
cvs.freedesktop.org:/cvs/xprint is no longer be used for real work) was
only for the Xprint server since that was the part which was completely
broken.
The client-side extension library ("libXp.so") only had one bug in the
thread support which we fixed long long ago (AFAIK that fix was even
part of X11R6.7.0).
> (only xprint libs & headers I could find were in the monolithic tree)
>
> [1]
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/libXp-autotools.patch?rev=1.1
Daniel:
Is the patch OK for you ?
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From loc at toya.net.pl Thu Jul 15 01:27:32 2004
Date: Thu Jul 15 01:27:38 2004
In-Reply-To: <20040714230900.GE15281@fooishbar.org>
References: <20040714230900.GE15281@fooishbar.org>
Message-ID: <40F63FF4.7090805@toya.net.pl>
Daniel Stone wrote:
> Hi guys,
> I've been doing battle royale with the monolithic tree for a while now,
> and have been immensely frustated by the inconsistency of #includes. So,
> for debrix, I *will* *not* *accept* patches that do not have
> exported/whatever includes in #include <X11/foo.h> form. This goes for
> all subdirectories as well - <X11/extensions/foo.h>, <X11/fonts/foo.h>,
> whatever. There are a couple of these throughout the drivers; I'll fix
> them up later on this week.
Good idea.
What about this two patches we (Jakub and Jakub) have sent (I know I'm a
pain in the ass but I would really like to know ;)?
PS. What about adding some info about getting into debrix development on
debrix.fd.o? The HowToEasilySetUpAnArchBranch thing.
--
Regards,
Jakub Piotr C?apa
From loc at toya.net.pl Thu Jul 15 01:37:15 2004
Date: Thu Jul 15 01:37:20 2004
In-Reply-To: <40F5F774.F787CA09@nrubsig.org>
References: <40F105D7.5010003@toya.net.pl> <40F5F774.F787CA09@nrubsig.org>
Message-ID: <40F6423B.3060100@toya.net.pl>
Roland Mainz wrote:
> Jakub Piotr C?apa wrote:
>
>>I've made an autotooling patch [1] for libXp. It's not ideal, probably
>>the automake autoadded files are just plain wrong but it works. :)
>>
>>Before you ask: xprint (from mozdev.org) does not provide any libs.
>
> Yup, the old Xprint tree (which means: The new repository for Xprint is
> now cvs.freedesktop.org:/cvs/xorg itself, the
> cvs.freedesktop.org:/cvs/xprint is no longer be used for real work) was
> only for the Xprint server since that was the part which was completely
> broken.
> The client-side extension library ("libXp.so") only had one bug in the
> thread support which we fixed long long ago (AFAIK that fix was even
> part of X11R6.7.0).
That's what I thought (there was an info about merging on the mozdev
page) but I also found a note in archives [1] which suggested that the
lib should be there too... (yes, it was outdated and not really true)
PS. Any comments about the autotools thing are welcome. Sadly, I've
never read this big fat manual about autotools and I'm only basing on
the other scripts I found here (in the xlibs and the debrix repo).
[1] http://freedesktop.org/pipermail/xlibs/2004-April/000287.html
--
Regards,
Jakub Piotr C?apa
From eich at pdx.freedesktop.org Thu Jul 15 02:40:24 2004
Date: Thu Jul 15 03:03:20 2004
In-Reply-To: alan@lxorguk.ukuu.org.uk wrote on Tuesday,
13 July 2004 at 19:42:15 +0100
Alan Cox writes:
> On Maw, 2004-07-13 at 20:18, Jesse Barnes wrote:
> > Sure, that would be even better. For legacy space, size would usually be 6
4k,
> > right? Or would we want to add a 'base' argument and allow callers to just

> > map the ports they're interested in?
>
> For platforms where port space can be bigger than 16bit and when port
> space is mmio mapped I can see it helping.
Are there such platforms - and is this relevant at all today?
I always thought that PIO was a cheap way of implementing HW
access in days where you only had 16 memory address lines and
address decoders were expensive so that you only wanted to
decode a few address lines.
Therefore today I'd expect MMIO would be the method of choice
if HW required more than a few ports or does not have to care
about legacy.
Egbert.
From torgeir at pobox.com Thu Jul 15 03:18:56 2004
Date: Thu Jul 15 03:22:38 2004
On Wed, 2004-07-14 at 10:39 -0700, Jon Smirl wrote:
> I see that keithp is running the KS session about video drivers.
Will there be an audio (and video) webcast of the summit?
--
Date: Thu Jul 15 03:25:32 2004
In-Reply-To: jonsmirl@yahoo.com wrote on Wednesday,
14 July 2004 at 10:39:19 -0700
Jon Smirl writes:
> I see that keithp is running the KS session about video drivers. It
> might be useful to hash this out with the X developers since a lot of
> people at Kernel Summit don't work with graphics cards. Many of these
> things have been discussed on this an other lists before.
>
> First is a basic assumption, there are two kinds of display output from
> the system:
> 1) kernel stuff - printk, kernel boot, kdbg, OOPS. Kernel stuff can
> have a high display priority and optionally override other displays,
> for example a kernel OOPS while you are running X. Since the system
> just crashed getting that OOPS on the screen is the most important
> thing in the system. Kernel display can not use userspace code since
> user space may be dead.
Right. It doesn't have to.
As long as the kernel knows the framebuffer parameters
(depth, bpp, location, size, stride, current start address)
it can dump anything to it.
The only obstacle may be an active 2D or 3D engine:
- Some chipsets don't like it if you dump things into the fb when
an accelerator is active.
- The kernel could interrogate the 3D driver to find out about the state
of the HW.
- The entire 2D code could be put into the kernel so it could be dealt with
the same way - not my favorite solution and not feasable for the range
of HW that is in use.
- A small piece of HW dependent code could be in the kernel to probe the
HW state.
- The kernel could just wait for a while and hope that the engine is
idle.
> 2) everything else
>
> Now working from this assumption, the video driver must have a kernel
> entry point for drawing to the screen. This entry point has to be
> optionally able to force itself onto the screen.
Why?
The framebuffer is just a range in the memory address space of the
kernel. So it can write to it whatever it wants.
The only problem I see is the status of the 2D and 3D engines.
>
> Next there are a bunch of discussion points about how to build
> everything else...
> 1) SAK - how to achive a guaranteed secure login that can't be trojaned
> 2) multiuser support - supporting multiple cards and different users
> logged into each head, both at the console level and X level
> 3) after looking at multiuser you will want to move the VT system to
> user space, how can this be done?
> 4) should there be a standard IOCTL interface to video drivers, or
> should the IOCTL interface to drivers be private and the published API
> be a library API?
We may need both.
> 5) If an OOPS needs to interrupt X, how can it draw? Should the OOPS
> attempt to change the display mode, or should the OOPS code be general
> enough to clear and draw the display without changing the mode?
Generally there is no need to change the video mode.
You just paint into the framebuffer - without worrying what else is
in there.
> 6) What about an OOPS during an uninterruptable graphics operation?
> should the kernel drivers force the complete atomic operation to be
> submitted to the kernel before starting the operation in order to
> guarantee that it can be finished if user space is dead?
> 7) should there be a single device driver for each card or should the
> kernel implement a robust system for multitasking different drivers
> onto the hardware
I'd prefer a single device driver.
However before we have all drivers ported to the new model (with all
features and capabilities) one needs to be prepared that people use
'other' drivers for certain HW.
> 8) kernel drawing does not need acceleration. If the VT system and user
> consoles are running from user space could they use a user space
> library for acceleration instead of the existing fbdev model?
I would prefer if as little as possible lives in kernel space.
> 9) what should the driver IOCTL interface look like? fbdev, DRI,
> something new?
I think can be decided best after one knows what needs to live within
the kernel.
> 10) Should user space hardware access from things like X be blocked?
> Instead a 2D XAA driver would be moved to an external library and X
> would call this library. The library would be granted hardware access.
> The point of the external library is to allow coordinated access to it
> from non-X apps like user console and user space VT implementations.
> Hardware access would be blocked from all apps, not just X. Everyone
> would have to use the library.
With library you probably refer to something not living in the address
space of the application itself.
> 11) what is the future of VGA mode? how will it be controlled with
> multiple cards are present?
There is a wide range of hardware around that still requires some
VGA support. Depriving user of this HW of a feature that they have
been using for a long time would make them very unhappy.
In an multi card, multi seat environment it is necessary to have a
central agent to control this.
There are two parts to it:
1. Keep track of which device currently has VGA access.
2. Control VGA access (bus routing etc).
We probably want to do 1. in user space while 2. could be handled
in kernel space.
Please note:
a. I the X server we presently don't restrict resource
sharing to VGA registers - VGA matters only as far as bus routing
is concerned - we support it for arbitrary registers. This can
matter on HW that still requires 8514 (or other legacy standard)
registers.
b. When two devices share the same address space for some registers
one device is taken off the bus (we can disable PIO and MMIO separately).
That means: anything that needs to draw to this address space
has to either go thru the agent that controls the access or
has to enable access itself (which would be the case when the
kernel needs to dump oopses).
> 12) How is mode setting handled? Is everything done in the kernel?
> Everything in user space? How about computing the register values
> needed for achieving the valid modes in user space and the storing the
> values in the driver. If you use a KVM switch you need to recompute.
I personally favor a model where mode setting can be kept outside of
the kernel. If a user mode app does mode setting and notifes the kernel
about the mode parameters (framebuffer location) it should be sufficient.
Display hot plugging requires a lot more.
> 13) How do secondary cards get reset in a multicard system?
You always keep it in some mode. Sometimes it may be desireable to
be able to repost a card (if something went awfully wrong).
> 14) How are we going to get all the groups working together and
> building a coordinated system?
>
That's definitely a good question!
Cheers,
Egbert.
From zhirnyi at yahoo.com Thu Jul 15 03:27:33 2004
From: zhirnyi at yahoo.com (ANDREI LAHUN)
Date: Thu Jul 15 03:34:16 2004
Subject: [Xorg] Debrix-Dead
Sorry for question, but what does this mean?
Debrix moved from CVS to anotehr place ?
Where can i get latest version?
Andrei.
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
From drewmasters at gmail.com Thu Jul 15 03:53:16 2004
From: drewmasters at gmail.com (Drew Masters)
Date: Thu Jul 15 03:53:22 2004
Subject: [Xorg] Triple outputs 1 AGP dual Head 1 PCI dual head
In-Reply-To: <3f42e9420407141545fd8f78e@mail.gmail.com>
References: <3f42e9420407141545fd8f78e@mail.gmail.com>
Message-ID: <3f42e94204071503537fd97218@mail.gmail.com>
Hi, I'm currently running 2 graphics cards, one is a dual head Radeon
9800, the other is a dual head Radeon 7000. I can get both of these
cards working independently using Xorg. However i wish to run them
concurrently (although only using one head on the 7000). Whenever I
run startx the 9800 ouputs work whereas I get a no matching device
section.... error for the 7000. lspci returns the BusIds I'm using in
xorg.conf, I've reached the end of guessing what's causing it, I'm
stumped. Any ideas?
(I could be overlooking something horrendously obvious)
Cheers
Drew
I attach my xorg.conf file.
-------------- next part --------------
Name: xorg.conf
Size: 25910 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040715/2733380b/xorg-0
001.obj
From michel at daenzer.net Thu Jul 15 03:59:10 2004
Date: Thu Jul 15 04:11:07 2004
In-Reply-To: <3f42e94204071503537fd97218@mail.gmail.com>
<3f42e94204071503537fd97218@mail.gmail.com>
On Thu, 2004-07-15 at 10:53 +0000, Drew Masters wrote:
> Hi, I'm currently running 2 graphics cards, one is a dual head Radeon
> 9800, the other is a dual head Radeon 7000. I can get both of these
> cards working independently using Xorg. However i wish to run them
> concurrently (although only using one head on the 7000). Whenever I
> run startx the 9800 ouputs work whereas I get a no matching device
> section.... error for the 7000. lspci returns the BusIds I'm using in
> xorg.conf, I've reached the end of guessing what's causing it, I'm
> stumped. Any ideas?
The
Screen 2
in the Device Section for the 7000 might be the cause. Try 0 or 1 or
leaving it out altogether instead. If that doesn't help, please provide
the relevant parts of the server log.
--
Date: Thu Jul 15 04:28:07 2004
<16630.23379.534961.322805@xf11.fra.suse.de>
On Iau, 2004-07-15 at 11:24, Egbert Eich wrote:
> - The entire 2D code could be put into the kernel so it could be dealt with
> the same way - not my favorite solution and not feasable for the range
> of HW that is in use.
This pretty much essential for many non PC users so the code already
generally exists for bitmapped framebuffers in the kernel. It doesn't
need and frequently doesn't know any more about accelerators than to
wait for it.
> > Now working from this assumption, the video driver must have a kernel
> > entry point for drawing to the screen. This entry point has to be
> > optionally able to force itself onto the screen.
>
> Why?
> The framebuffer is just a range in the memory address space of the
> kernel. So it can write to it whatever it wants.
Not every framebuffer or similat device fits this description. In
essence you need chip specific function entry points for a lot of the
2D text rendering work. For almost all cards they happen to point to
the same functions
> 1. Keep track of which device currently has VGA access.
> 2. Control VGA access (bus routing etc).
> We probably want to do 1. in user space while 2. could be handled
> in kernel space.
#1 has to be partly in kernel space the moment there are multiple
independant X servers or other display engines around. hotplug, sak,
and the kernel itself may well be involved in wanting to touch VGA
register space.
From marcogh at linux.it Thu Jul 15 05:38:13 2004
From: marcogh at linux.it (marco ghidinelli)
Date: Thu Jul 15 05:57:54 2004
Subject: [Xorg] Debrix-Dead
Message-ID: <20040715123813.GA3506@chiocciolina.it>
On Thu, Jul 15, 2004 at 03:27:33AM -0700, ANDREI LAHUN wrote:
> Sorry for question, but what does this mean?
> Debrix moved from CVS to anotehr place ?
maybe in arch? http://debrix.freedesktop.org/
--
BOFH excuse #6:
global warming
From jbarnes at engr.sgi.com Thu Jul 15 06:20:23 2004
Date: Thu Jul 15 06:20:30 2004
On Thursday, July 15, 2004 6:18 am, Torgeir Veimo wrote:
> On Wed, 2004-07-14 at 10:39 -0700, Jon Smirl wrote:
> > I see that keithp is running the KS session about video drivers.
>
> Will there be an audio (and video) webcast of the summit?
No, I don't think so, but it's been discussed a few times now, so things may
change...
Jesse
Date: Thu Jul 15 06:29:13 2004
In-Reply-To: <ye87jt6k89n.fsf@horse04.daimi.au.dk>
<ye87jt6k89n.fsf@horse04.daimi.au.dk>
Message-ID: <ye87jt5juqu.fsf@horse07.daimi.au.dk>
> Soeren Sandmann <sandmann@daimi.au.dk> writes:
>
> > On bug 839
> >
> > http://freedesktop.org/bugzilla/show_bug.cgi?id=839
> >
> > there is a patch adding faster versions of some the render ops.
>
> Unless someone speaks up, I'll commit the speedups on Friday.
Note that there is still a problem with the Imakefile changes:
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/fb/Imakefile,v
diff -u -r1.3 Imakefile
--- programs/Xserver/fb/Imakefile 30 Jun 2004 20:06:53 -0000 1.3
+++ programs/Xserver/fb/Imakefile 2 Jul 2004 20:13:23 -0000
@@ -3,6 +3,11 @@
XCOMM
XCOMM Id: Imakefile,v 1.1 1999/11/02 03:54:44 keithp Exp $

+#if defined(i386Architecture) && defined(HasGcc34) && HasGcc34
+#undef DefaultCCOptions
+#define DefaultCCOptions -mmmx -Winline --param inline-unit-growth=10000 --para
m large-function-growth=10000 -DUSE_GCC34_MMX
+#endif
+
This essentially *changes* DefaultCCOptions for all of the framebuffer
code, which is not very nice. The problem is
(a) MMX intrinsics don't work with -pedantic
(b) DefaultCCOptions includes -pedantic
(c) There is no way to _remove_ options from DefaultCCOptions
Also, the code is written in a way that needs gcc's default inline
heuristics to be turned off, but that's not a problem because you can
easily *add* options to DefaultCCOptions.
If someone has a clean solution, please let me know.
Personally I am inclined to just remove -pedantic from
DefaultCCOptions, because the option it isn't really that useful.
S?ren
Date: Thu Jul 15 06:41:33 2004
In-Reply-To: <40F63FF4.7090805@toya.net.pl>
<40F63FF4.7090805@toya.net.pl>
Message-ID: <40F68923.4000403@bitplanet.net>
>
>> Hi guys,
>> I've been doing battle royale with the monolithic tree for a while now,
>> and have been immensely frustated by the inconsistency of #includes. So,
>> for debrix, I *will* *not* *accept* patches that do not have
>> exported/whatever includes in #include <X11/foo.h> form. This goes for
>> all subdirectories as well - <X11/extensions/foo.h>, <X11/fonts/foo.h>,
>> whatever. There are a couple of these throughout the drivers; I'll fix
>> them up later on this week.
>
>
> Good idea.
>
> What about this two patches we (Jakub and Jakub) have sent (I know I'm a
> pain in the ass but I would really like to know ;)?
>
> PS. What about adding some info about getting into debrix development on
> debrix.fd.o? The HowToEasilySetUpAnArchBranch thing.
I added a short blurb on debrix.fd.o on how to create a local branch.
Not very explanatory, but it should get you going. The full story is on
http://gnuarch.org/tutorial/html/arch.html.
Kristian
From drewmasters at gmail.com Thu Jul 15 05:32:32 2004
From: drewmasters at gmail.com (Drew Masters)
Date: Thu Jul 15 08:19:16 2004
<3f42e94204071503537fd97218@mail.gmail.com>
<1089889150.11232.13.camel@localhost>
Message-ID: <3f42e942040715053258662bcc@mail.gmail.com>
Cheers
That solved the initial problem, howver the system crashes hard after
displaying the desktop. The Xorg.0.log appears different every time,
usually with garbled data that appears to be the result of setting up
the previous session (html code etc) and occaisonally containing
excerpts from the xorg.conf file. The xorg.conf file itself also
appears to become corrupted, both with excerpts from the *previous*
xorg.conf file and random data that is injected at various intervals.
On Thu, 15 Jul 2004 12:59:10 +0200, Michel D?nzer <michel@daenzer.net> wrote:
> On Thu, 2004-07-15 at 10:53 +0000, Drew Masters wrote:
> > Hi, I'm currently running 2 graphics cards, one is a dual head Radeon
> > 9800, the other is a dual head Radeon 7000. I can get both of these
> > cards working independently using Xorg. However i wish to run them
> > concurrently (although only using one head on the 7000). Whenever I
> > run startx the 9800 ouputs work whereas I get a no matching device
> > section.... error for the 7000. lspci returns the BusIds I'm using in
> > xorg.conf, I've reached the end of guessing what's causing it, I'm
> > stumped. Any ideas?
>
> The
>
> Screen 2
>
> in the Device Section for the 7000 might be the cause. Try 0 or 1 or
> leaving it out altogether instead. If that doesn't help, please provide
> the relevant parts of the server log.
>
>
> --
> Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
> Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
>
>
Date: Thu Jul 15 08:43:17 2004
In-Reply-To: jbarnes@engr.sgi.com wrote on Tuesday,
13 July 2004 at 15:40:47 -0400
<16628.13144.707374.160606@xf11.fra.suse.de>
> On Tuesday, July 13, 2004 3:25 pm, Jesse Barnes wrote:
> > On Tuesday, July 13, 2004 3:09 pm, Egbert Eich wrote:
> > > Jesse Barnes writes:
> > > > In the arch specific in/out routines you mean? I see lots of lines
> > > > like inb(0x3c8) in various drivers and other code...
> > >
> > > Can you point me to them, please?
> >
> > There are too many to list. Just do a 'grep -r inb' in hw/xorg. Many of
> > the inb calls refer to a base, but in some cases (maybe all cases) the
> > IOBase is assumed to be global and unique, rather than per-device or
> > per-bus.
>
> Actually, now that I've looked at it some more, it's not *that* bad. There
> are some places that use absolute values, but many are relative to a base.
> Not all platforms support it though, since many declare their in/out routines

> to take unsigned short values...
>
The 'classic' PIO range was 16bit and I don't think you can do more on the
platforms that have this limit.
We certainly need to see what we do about the absolute values - in some
cases they are probably used intentionally.
All this code is going to be revisited when things get restructured.
Egbert.
Date: Thu Jul 15 09:38:23 2004
<16630.20744.802143.228327@xf11.fra.suse.de>
On Thursday, July 15, 2004 5:40 am, Egbert Eich wrote:
> Alan Cox writes:
> > On Maw, 2004-07-13 at 20:18, Jesse Barnes wrote:
> > > Sure, that would be even better. For legacy space, size would usually
> > > be 64k, right? Or would we want to add a 'base' argument and allow
> > > callers to just map the ports they're interested in?
> >
> > For platforms where port space can be bigger than 16bit and when port
> > space is mmio mapped I can see it helping.
>
> Are there such platforms - and is this relevant at all today?
Yes, and I think so.
> I always thought that PIO was a cheap way of implementing HW
> access in days where you only had 16 memory address lines and
> address decoders were expensive so that you only wanted to
> decode a few address lines.
> Therefore today I'd expect MMIO would be the method of choice
> if HW required more than a few ports or does not have to care
> about legacy.
Right, I think most drivers will use MMIO once they're up. However, POSTing
devices with x86 option ROMs means using legacy I/O ports.
Jesse
From idr at us.ibm.com Thu Jul 15 08:54:18 2004
Date: Thu Jul 15 09:50:25 2004
References: <20040714173919.46093.qmail@web14925.mail.yahoo.com> <1089886
736.2970.0.camel@dogfish.marketpipe.com>
Message-ID: <40F6A8AA.3000406@us.ibm.com>
Jesse Barnes wrote:
> On Thursday, July 15, 2004 6:18 am, Torgeir Veimo wrote:
>
>>On Wed, 2004-07-14 at 10:39 -0700, Jon Smirl wrote:
>>
>>>I see that keithp is running the KS session about video drivers.
>>
>>Will there be an audio (and video) webcast of the summit?
>
> No, I don't think so, but it's been discussed a few times now, so things may
> change...
If nothing else, would it be possible to video and / or audio record
certain sessions and make them available after the fact?
From idr at us.ibm.com Thu Jul 15 08:58:55 2004
Date: Thu Jul 15 09:52:43 2004
In-Reply-To: <ye87jt5juqu.fsf@horse07.daimi.au.dk>
References: <ye87jtewhza.fsf@ec02.daimi.au.dk> <ye87jt6k89n.fsf@horse04.daimi.a
u.dk>
<ye87jt5juqu.fsf@horse07.daimi.au.dk>
Message-ID: <40F6A9BF.7070807@us.ibm.com>
> This essentially *changes* DefaultCCOptions for all of the framebuffer
> code, which is not very nice. The problem is
>
> (a) MMX intrinsics don't work with -pedantic
>
> (b) DefaultCCOptions includes -pedantic
>
> (c) There is no way to _remove_ options from DefaultCCOptions
>
> Also, the code is written in a way that needs gcc's default inline
> heuristics to be turned off, but that's not a problem because you can
> easily *add* options to DefaultCCOptions.
>
> If someone has a clean solution, please let me know.
>
> Personally I am inclined to just remove -pedantic from
> DefaultCCOptions, because the option it isn't really that useful.
Would it maybe be better to add something like StrictCCWarningOptions
that include -pedantic and is used only where it will work (i.e., every
place that doesn't use MMX intrinsics)? I've run into similar
irritations before.
From sn4ip3r at sn4ip3r.dyn.ee Thu Jul 15 09:40:33 2004
From: sn4ip3r at sn4ip3r.dyn.ee (sn4ip3r@sn4ip3r.dyn.ee)
Date: Thu Jul 15 10:00:29 2004
Subject: [Xorg] Strange crashes caused by radeon pagesize cleanup/update?
Message-ID: <47018.80.235.39.61.1089909633.squirrel@80.235.39.61>
The latest X.org (from CVS date:2004-07-13) seems to crash while opening
or resizing some gtk windows, I didn't investigate it much, but server
crashes (Fatal server error: Caught signal 11. Server aborting) were
caused by opening xfce4-mixer, evolution-1.5, gtk file save dialog,
rhythmbox (all of those, including gtk are also latest CVS versions,
but I don't think gtk could cause this).
Anyway, I tried Xorg from 2004-07-09 and it worked fine, then I applied
the updates to radeon_dri.c and r128_dri.c and got the same problem as
with 2004-07-13.
I'm also using the latest radeon drm driver from Xorg cvs, radeon 9000
pro 64MB, gcc-3.4.1 (also tried 3.3.3), linux-2.6.7-rc3,
glibc-2.3.4.20040619.
(btw. I made a small test program and getpagesize() did return 4096.)
-- This seem to be the cause of the problem:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/driver
s/ati/r128_dri.c?r1=1.3&r2=1.4&root=xorg
It's also possible that the problem occurs on r128 but I can't test that.
Strange thing is that the patch is very simple and doesn't look like it
could cause the server to crash, but maybe I'm missing something.
Date: Thu Jul 15 10:06:59 2004
In-Reply-To: <40F6A8AA.3000406@us.ibm.com>
<40F6A8AA.3000406@us.ibm.com>
On Thursday, July 15, 2004 11:54 am, Ian Romanick wrote:
> If nothing else, would it be possible to video and / or audio record
> certain sessions and make them available after the fact?
I don't think they'll be recorded at all. People were concerned that
recording and/or streaming would chill an otherwise spirited discussion.
Like I said though, that might change, but probably not this year.
Jesse
From matt at killermookie.org Thu Jul 15 10:09:56 2004
From: matt at killermookie.org (Matthew Sims)
Date: Thu Jul 15 10:10:12 2004
Subject: [Xorg] BadDrawable when fowarding display
Hello all,
I searched a little through the archives and have been combing over Google
Groups to find any help with my issue. I hope this is the correct mailing
list for this.
I just installed Slackware 10. A fresh, clean install. My X version:
Build Operating System: Linux 2.4.26 i686 [ELF]
Current Operating System: Linux tron 2.4.26 #21 Mon Jun 14 19:17:44
PDT 2004 i686
Build Date: 05 June 2004
Now I had a problem forwarding X displays to this new linux setup. At
first I was simply getting a "Unable to open display" error. I ended
up recreating the .Xauthority and it helped...somewhat.
I can forward over /usr/openwin/bin/xlogo and admintool (the remote
server is Solaris). But I can't forward a third-party application. I
get this error now:
X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
Major opcode of failed request: 73 (X_GetImage)
Resource id in failed request: 0x40
Serial number of failed request: 132
Current serial number in output stream: 132
>From what I've read around the internet, I get the feeling that the
app is having issues drawing itself on my local desktop due to a
possible naming problem or resolution issue? I couldn't find anything
a little more specific.
I did a man on XGetImage and it does make a mention about BadDrawable
but I'm unable to follow what it means and what I should look for.
Maybe someone could point to some possible items to check out? :)
--Matthew Sims
--<http://killermookie.org>
From jonsmirl at yahoo.com Thu Jul 15 10:13:28 2004
Date: Thu Jul 15 10:20:12 2004
In-Reply-To: <40F6A8AA.3000406@us.ibm.com>
The talk is on Monday. Keith and others attending the conference will
see everything you write here before then.
Monday
3:30 - Video Drivers
Session chair: Keith Packard
There is also an X/Desktop developer conference happening at the same
time. I suspect more detailed conversations will happen there.
http://www.desktopcon.org/2004/
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Thu Jul 15 10:59:53 2004
In-Reply-To: <60050.208.44.135.18.1089911396.squirrel@208.44.135.18>
References: <60050.208.44.135.18.1089911396.squirrel@208.44.135.18>
On Thu, 2004-07-15 at 10:09 -0700, Matthew Sims wrote:
>
> Now I had a problem forwarding X displays to this new linux setup. At
> first I was simply getting a "Unable to open display" error. I ended
> up recreating the .Xauthority and it helped...somewhat.
>
> I can forward over /usr/openwin/bin/xlogo and admintool (the remote
> server is Solaris). But I can't forward a third-party application. I
> get this error now:
>
> X Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
> Major opcode of failed request: 73 (X_GetImage)
> Resource id in failed request: 0x40
> Serial number of failed request: 132
> Current serial number in output stream: 132
If you're forwarding with ssh >= 3.8, is ForwardX11Trusted enabled
there?
--
From: sn4ip3r at sn4ip3r.dyn.ee (Tarmo =?iso-8859-1?Q?T=E4nav?=)
Date: Thu Jul 15 11:18:51 2004
Sorry, the correct link for radeon_dri.c is actually:
http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/driver
s/ati/radeon_dri.c?r1=1.4&r2=1.5&root=xorg
> The latest X.org (from CVS date:2004-07-13) seems to crash while opening
> or resizing some gtk windows, I didn't investigate it much, but server
> crashes (Fatal server error: Caught signal 11. Server aborting) were
> caused by opening xfce4-mixer, evolution-1.5, gtk file save dialog,
> rhythmbox (all of those, including gtk are also latest CVS versions,
> but I don't think gtk could cause this).
>
> Anyway, I tried Xorg from 2004-07-09 and it worked fine, then I applied
> the updates to radeon_dri.c and r128_dri.c and got the same problem as
> with 2004-07-13.
>
> I'm also using the latest radeon drm driver from Xorg cvs, radeon 9000
> pro 64MB, gcc-3.4.1 (also tried 3.3.3), linux-2.6.7-rc3,
> glibc-2.3.4.20040619.
>
> (btw. I made a small test program and getpagesize() did return 4096.)
>
> -- This seem to be the cause of the problem:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/driv
ers/ati/r128_dri.c?r1=1.3&r2=1.4&root=xorg
>
> It's also possible that the problem occurs on r128 but I can't test that.
> Strange thing is that the patch is very simple and doesn't look like it
> could cause the server to crash, but maybe I'm missing something.
> _______________________________________________
> xorg mailing list
>
Date: Thu Jul 15 11:29:39 2004
<1089914386.22276.4.camel@localhost>
> On Thu, 2004-07-15 at 10:09 -0700, Matthew Sims wrote:
>>
>> Now I had a problem forwarding X displays to this new linux setup. At
>> first I was simply getting a "Unable to open display" error. I ended
>> up recreating the .Xauthority and it helped...somewhat.
>>
>> I can forward over /usr/openwin/bin/xlogo and admintool (the remote
>> server is Solaris). But I can't forward a third-party application. I
>> get this error now:
>>
>> X Error of failed request: BadDrawable (invalid Pixmap or Window
>> parameter)
>> Major opcode of failed request: 73 (X_GetImage)
>> Resource id in failed request: 0x40
>> Serial number of failed request: 132
>> Current serial number in output stream: 132
>
> If you're forwarding with ssh >= 3.8, is ForwardX11Trusted enabled
> there?
My Slackware box is using OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
I looked at sshd_config and there's no such listing as ForwardX11Trusted.
--Matthew Sims
Date: Thu Jul 15 12:01:21 2004
<1089914386.22276.4.camel@localhost>
<60255.208.44.135.18.1089916563.squirrel@208.44.135.18>
On Thu, 2004-07-15 at 11:36 -0700, Matthew Sims wrote:
> > On Thu, 2004-07-15 at 10:09 -0700, Matthew Sims wrote:
> >>
> >> X Error of failed request: BadDrawable (invalid Pixmap or Window
> >> parameter)
> >> Major opcode of failed request: 73 (X_GetImage)
> >> Resource id in failed request: 0x40
> >> Serial number of failed request: 132
> >> Current serial number in output stream: 132
> >
> > If you're forwarding with ssh >= 3.8, is ForwardX11Trusted enabled
> > there?
>
> My Slackware box is using OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
>
> I looked at sshd_config and there's no such listing as ForwardX11Trusted.
It's only mentioned in ssh_config here as well. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237021 for more
information.
--
Date: Thu Jul 15 12:09:50 2004
<1089914386.22276.4.camel@localhost>
<60255.208.44.135.18.1089916563.squirrel@208.44.135.18>
<1089918069.22240.6.camel@localhost>
> On Thu, 2004-07-15 at 11:36 -0700, Matthew Sims wrote:
>> > On Thu, 2004-07-15 at 10:09 -0700, Matthew Sims wrote:
>> >>
>> >> X Error of failed request: BadDrawable (invalid Pixmap or Window
>> >> parameter)
>> >> Major opcode of failed request: 73 (X_GetImage)
>> >> Resource id in failed request: 0x40
>> >> Serial number of failed request: 132
>> >> Current serial number in output stream: 132
>> >
>> > If you're forwarding with ssh >= 3.8, is ForwardX11Trusted enabled
>> > there?
>>
>> My Slackware box is using OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
>>
>> I looked at sshd_config and there's no such listing as
>> ForwardX11Trusted.
>
> It's only mentioned in ssh_config here as well. See
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237021 for more
> information.
>
The -Y option worked! YAY! YAYAYAYAYAYAY!
Thanks Michel. :)
--Matthew Sims
From: sn4ip3r at sn4ip3r.dyn.ee (Tarmo =?iso-8859-1?Q?T=E4nav?=)
Date: Thu Jul 15 12:34:31 2004
<47617.80.235.39.61.1089915443.squirrel@80.235.39.61>
I mixed some things up:
06-30 -- WORKS
06-30 no DRI -- WORKS
07-09 -- CRASH
07-09 no DRI -- WORKS
07-13 -- CRASH
07-13 no DRI -- CRASH
> Sorry, the correct link for radeon_dri.c is actually:
> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/driv
ers/ati/radeon_dri.c?r1=1.4&r2=1.5&root=xorg
>
>> The latest X.org (from CVS date:2004-07-13) seems to crash while opening
>> or resizing some gtk windows, I didn't investigate it much, but server
>> crashes (Fatal server error: Caught signal 11. Server aborting) were
>> caused by opening xfce4-mixer, evolution-1.5, gtk file save dialog,
>> rhythmbox (all of those, including gtk are also latest CVS versions,
>> but I don't think gtk could cause this).
>>
>> Anyway, I tried Xorg from 2004-07-09 and it worked fine, then I applied
>> the updates to radeon_dri.c and r128_dri.c and got the same problem as
>> with 2004-07-13.
>>
>> I'm also using the latest radeon drm driver from Xorg cvs, radeon 9000
>> pro 64MB, gcc-3.4.1 (also tried 3.3.3), linux-2.6.7-rc3,
>> glibc-2.3.4.20040619.
>>
>> (btw. I made a small test program and getpagesize() did return 4096.)
>>
>> -- This seem to be the cause of the problem:
>> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/dri
vers/ati/r128_dri.c?r1=1.3&r2=1.4&root=xorg
>>
>> It's also possible that the problem occurs on r128 but I can't test
>> that.
>> Strange thing is that the patch is very simple and doesn't look like it
>> could cause the server to crash, but maybe I'm missing something.
From bart at verwilst.be Thu Jul 15 15:10:33 2004
From: bart at verwilst.be (Bart Verwilst)
Date: Thu Jul 15 15:37:01 2004
Subject: [Xorg] Status of IGP320 3D support?
Message-ID: <200407160010.33148.bart@verwilst.be>
Hello!
I was wondering what the status of 3D support for Radeon Mobility cards
(IGP320 chipset, amongst others) is in xorg's CVS? I know there is a very
longstanding bug about this on XFree86's list:
( http://bugs.xfree86.org/show_bug.cgi?id=314 ). Does anybody knows wether
this has already been merged, and will be available in xorg 6.7.1 or
something? :)
Thanks a lot!
Bart Verwilst
From bart at verwilst.be Thu Jul 15 16:10:17 2004
Date: Thu Jul 15 16:32:30 2004
In-Reply-To: <a728f9f904071515564aaff334@mail.gmail.com>
References: <200407160010.33148.bart@verwilst.be>
<a728f9f904071515564aaff334@mail.gmail.com>
Message-ID: <200407160110.17664.bart@verwilst.be>
On Friday 16 July 2004 00:56, you wrote:
|| I believe it was merged with DRI merge a few weeks back.
||
|| Alex
Sweet! Great to hear this :)
So, will that merge be in 6.7.1? Or only in 6.8 or something? :$
Thanks!
Bart
From acosta at ar.microlink.com.br Thu Jul 15 17:13:46 2004
From: acosta at ar.microlink.com.br (Andre Costa)
Date: Thu Jul 15 17:07:41 2004
Subject: [Xorg] GTK 1.x + TTF on Fedora Core 2 anyone?
Message-ID: <20040715211346.4ff94d1d.acosta@ar.microlink.com.br>
Hi all,
please apologize if this is not the right place to ask this.
I have recently upgraded from Fedora Core 1 to FC2, and I can't seem to
be able to use TTF with GTK 1.x apps anymore -- fonts are listed by
xlsfonts, but they appear ugly. Compare the results:
http://gwpr03.microlink.com.br/~acosta/Sylpheed-FC1.png
http://gwpr03.microlink.com.br/~acosta/Sylpheed-FC2.png
(former shows proper Verdana font rendering, latter shows weird
rendering)
Font used is:
-microsoft-verdana-medium-r-normal-*-*-90-*-*-p-*-iso8859-1
Please refer to the original post on Fedora ML for further info about
the installation/setup:
http://www.redhat.com/archives/fedora-list/2004-July/msg02895.html
TIA
Andre
PS: MS TTF appear just fine on GTK2 apps.
--
Andre Oliveira da Costa
From: sn4ip3r at sn4ip3r.dyn.ee (Tarmo =?ISO-8859-1?Q?T=E4nav?=)
Date: Thu Jul 15 17:40:33 2004
<47617.80.235.39.61.1089915443.squirrel@80.235.39.61>
<48094.80.235.39.61.1089919983.squirrel@80.235.39.61>
Message-ID: <1089938441.4160.8.camel@sn4ip3r-1>
Well, found another thing, by only using 6-30
When I accidentially defined my like this:
Depth 24
Modes "1280x1024" "1280x960" "1152x864" "1024x768"
"800x600"
Modes "1280x960" "1152x864" "1024x768" "800x600"
Virtual 0 0
EndSubSection
it caused the same problem as with the other versions.
By removing either one of the "Modes" lines the problem didn't happen
anymore. What really happens if there are two "Modes" lines?
And I also found out that by using disabling Render acceleration like
this: Option "RenderAccel" "False"
the crashes ceased to happen.
Please tell me if there's anything else I should test or if I'm way
wrong and it is my own machine probably causing this problem.
--
Tarmo T?nav
sn4ip3r@sn4ip3r.dyn.ee / sn4ip3r@estprog.ee
On Thu, 2004-07-15 at 22:33 +0300, Tarmo T?nav wrote:
> I mixed some things up:
>
> 06-30 -- WORKS
> 06-30 no DRI -- WORKS
> 07-09 -- CRASH
> 07-09 no DRI -- WORKS
> 07-13 -- CRASH
> 07-13 no DRI -- CRASH
>
>
> > Sorry, the correct link for radeon_dri.c is actually:
> > http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/dr
ivers/ati/radeon_dri.c?r1=1.4&r2=1.5&root=xorg
> >
> >> The latest X.org (from CVS date:2004-07-13) seems to crash while opening
> >> or resizing some gtk windows, I didn't investigate it much, but server
> >> crashes (Fatal server error: Caught signal 11. Server aborting) were
> >> caused by opening xfce4-mixer, evolution-1.5, gtk file save dialog,
> >> rhythmbox (all of those, including gtk are also latest CVS versions,
> >> but I don't think gtk could cause this).
> >>
> >> Anyway, I tried Xorg from 2004-07-09 and it worked fine, then I applied
> >> the updates to radeon_dri.c and r128_dri.c and got the same problem as
> >> with 2004-07-13.
> >>
> >> I'm also using the latest radeon drm driver from Xorg cvs, radeon 9000
> >> pro 64MB, gcc-3.4.1 (also tried 3.3.3), linux-2.6.7-rc3,
> >> glibc-2.3.4.20040619.
> >>
> >> (btw. I made a small test program and getpagesize() did return 4096.)
> >>
> >> -- This seem to be the cause of the problem:
> >> http://freedesktop.org/cgi-bin/viewcvs.cgi/xc/programs/Xserver/hw/xfree86/d
rivers/ati/r128_dri.c?r1=1.3&r2=1.4&root=xorg
> >>
> >> It's also possible that the problem occurs on r128 but I can't test
> >> that.
> >> Strange thing is that the patch is very simple and doesn't look like it
> >> could cause the server to crash, but maybe I'm missing something.
>
>
> _______________________________________________
> xorg mailing list
From Stuart.Kreitman at Sun.COM Thu Jul 15 19:11:45 2004
From: Stuart.Kreitman at Sun.COM (Stuart Kreitman)
Date: Thu Jul 15 19:22:08 2004
Subject: [Xorg] How's it building?
Message-ID: <40F73961.5000503@sun.com>
I just attempted a clean checkout/make World on Solaris 9 and it breaks
in drivers/ati/radeon_accel.o, line 287. Anyone familiar with this issue?
skk
Date: Thu Jul 15 19:43:12 2004
In-Reply-To: <40F73961.5000503@sun.com>
References: <40F73961.5000503@sun.com>
Message-ID: <40F73D07.8080805@Sun.COM>
Stuart Kreitman wrote:
> I just attempted a clean checkout/make World on Solaris 9 and it breaks
> in drivers/ati/radeon_accel.o, line 287. Anyone familiar with this issue?
Oh yeah - I forgot to warn you about that - the DRI merge broke non-DRI
platforms like Solaris. See:
--
Date: Thu Jul 15 19:46:17 2004
In-Reply-To: <40F63FF4.7090805@toya.net.pl>
Message-ID: <20040716024615.GP15281@fooishbar.org>
On Thu, Jul 15, 2004 at 10:27:32AM +0200, Jakub Piotr C?apa wrote:
> What about this two patches we (Jakub and Jakub) have sent (I know I'm a
> pain in the ass but I would really like to know ;)?
Sorry, I still haven't looked at them.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/5df9dac8/attach
ment.pgp
From eta at lclark.edu Thu Jul 15 20:22:00 2004
Date: Thu Jul 15 20:27:05 2004
In-Reply-To: <40F73D07.8080805@Sun.COM>
References: <40F73961.5000503@sun.com> <40F73D07.8080805@Sun.COM>
On Thu, 2004-07-15 at 19:27, Alan Coopersmith wrote:
> Stuart Kreitman wrote:
> > I just attempted a clean checkout/make World on Solaris 9 and it breaks
> > in drivers/ati/radeon_accel.o, line 287. Anyone familiar with this issue?
>
> Oh yeah - I forgot to warn you about that - the DRI merge broke non-DRI
> platforms like Solaris. See:
OK. Your patch looked fine for the one, and I'm fixing Radeon now.
I'll commit them after testing. Sorry for the mess. A few thoughts
(that are not meant to be attacking in any way):
- It would be nice if we had a working tinderbox. The current setup is
totally broken.
- It would be nice to assign bugs to folks if it's not too hard to find
the guilty party (me).
- It would be nice if more committers were committing their patches.
Often when browsing bugs I say, "but the submitter is a committer, why
don't they do it themselves?
--
Date: Thu Jul 15 21:24:16 2004
<1089948119.896.11.camel@leguin>
Eric Anholt wrote:
> - It would be nice to assign bugs to folks if it's not too hard to find
> the guilty party (me).
I put you on the cc list, but wasn't sure if I should just outright assign
it to you.
> - It would be nice if more committers were committing their patches.
> Often when browsing bugs I say, "but the submitter is a committer, why
> don't they do it themselves?
I didn't commit this fix since I didn't have the hardware to verify I wasn't
breaking the driver, and don't have enough experience with the drivers & DRI
to feel comfortable checking in changes without testing or review. In areas
of the code I'm more familiar with, or when it's fairly obvious the fix is
correct, I generally do commit my fixes. Perhaps if we started more actively
using the "request review" feature in the new bugzilla version we could get
past this hurdle.
--
Date: Thu Jul 15 21:28:42 2004
In-Reply-To: <40F75478.2090207@Sun.COM>
<1089948119.896.11.camel@leguin> <40F75478.2090207@Sun.COM>
On Thu, 2004-07-15 at 21:07, Alan Coopersmith wrote:
> Eric Anholt wrote:
> > - It would be nice to assign bugs to folks if it's not too hard to find
> > the guilty party (me).
>
> I put you on the cc list, but wasn't sure if I should just outright assign
> it to you.
>
> > - It would be nice if more committers were committing their patches.
> > Often when browsing bugs I say, "but the submitter is a committer, why
> > don't they do it themselves?
>
> I didn't commit this fix since I didn't have the hardware to verify I wasn't
> breaking the driver, and don't have enough experience with the drivers & DRI
> to feel comfortable checking in changes without testing or review. In areas
> of the code I'm more familiar with, or when it's fairly obvious the fix is
> correct, I generally do commit my fixes. Perhaps if we started more actively
> using the "request review" feature in the new bugzilla version we could get
> past this hurdle.
I think people suffering from build failures caused by other committers
should be given a significant amount of leeway to fix it as best they
feel they can. It's cool, though. The Radeon was a little messier, so
you probably didn't want to try to fix it all anyway.
Certainly in my case at least, just assign when in doubt. I'll punt if
it's not really for me, and I'll notice it quicker anyway.
Thanks for the bugreports!
--
From alexdeucher at gmail.com Thu Jul 15 15:56:26 2004
Date: Thu Jul 15 23:03:14 2004
In-Reply-To: <200407160010.33148.bart@verwilst.be>
Message-ID: <a728f9f904071515564aaff334@mail.gmail.com>
On Fri, 16 Jul 2004 00:10:33 +0200, Bart Verwilst <bart@verwilst.be> wrote:
> Hello!
>
> I was wondering what the status of 3D support for Radeon Mobility cards
> (IGP320 chipset, amongst others) is in xorg's CVS? I know there is a very
> longstanding bug about this on XFree86's list:
> ( http://bugs.xfree86.org/show_bug.cgi?id=314 ). Does anybody knows wether
> this has already been merged, and will be available in xorg 6.7.1 or
> something? :)
I believe it was merged with DRI merge a few weeks back.
Alex
>
> Thanks a lot!
>
> Bart Verwilst
Date: Fri Jul 16 01:20:53 2004
In-Reply-To: <20040716024615.GP15281@fooishbar.org>
<20040716024615.GP15281@fooishbar.org>
Message-ID: <40F78FE0.6050809@toya.net.pl>
Daniel Stone wrote:
> On Thu, Jul 15, 2004 at 10:27:32AM +0200, Jakub Piotr C?apa wrote:
>
>>What about this two patches we (Jakub and Jakub) have sent (I know I'm a
>>pain in the ass but I would really like to know ;)?
>
> Sorry, I still haven't looked at them.
No problem. Just let us know when you do. :)
--
Regards,
Jakub Piotr C?apa
From P at draigBrady.com Fri Jul 16 02:04:57 2004
From: P at draigBrady.com (P@draigBrady.com)
Date: Fri Jul 16 02:14:19 2004
Subject: [Xorg] include xsel?
Message-ID: <40F79A39.5050400@draigBrady.com>
Right that's it. I've just needed to
use xsel for the 100th time.
http://www.niksula.cs.hut.fi/~vherva/xsel/
Is there any chance it could be included by default?
cheers,
P?draig.
From anuril at hotmail.com Fri Jul 16 09:22:35 2004
From: anuril at hotmail.com (Joe L.)
Date: Fri Jul 16 09:24:46 2004
Subject: [Xorg] xcompmgr
Message-ID: <BAY19-F181pyLosv8r80004c489@hotmail.com>
I've been trying to get xcompmgr to start up, but it seems that it can't
figure out how to interface the fixes, damage or composite extensions.
>From the Xserver compile HOWTO on freedesktop.org, it seems as though the
extensions don't require a line in /etc/X11/xorg.conf as certain other
modules do. If it does, the option is hidden pretty well -- I've been
googling for hours for examples of xorg.conf files that load damage or
composite extensions. I also tried lines similar to:
Load "damage", and
Load "Xdamage"
in hopes of hitting something by accident. Of course, these desperate
guesses never garnished any favorable results. I'm pretty convinced at this
point that xcompmgr isn't looking for an extension that one would expect to
show up in xdpyinfo's output. So I took a look at xcompmgr's source and
followed the X*QueryExtension functions back to the source for libXrender
and libXcomposite. The X*HasExtension macro ended up checking a `codes'
variable that is initialized via XInitExtension (in the case that the
X*ExtInfo checked doesn't have an entry for the current display in its list)
which ends up being exported in the libX11.so.6. Knowing that
XInitExtension is exported by the core X11 library leads me to believe that
the libXcomposite/libXdamage/libXfixes (although I didn't check the code for
damage and fixes) are the usual extensions that could (/should) be included
via a Load directive in the Modules section of /etc/X11/xorg.conf. The idea
of a load directive is, unfortunately, contradicted by the fact that the
sample xorg.conf file included via CVS contains no such Load statements --
and supposedly should work (i.e.: the XserverInstallGuide).
OTOH, the FD.o XserverInstallGuide exported LD_LIBRARY_PATH. I imagined
xcompmgr may be trying to load these modules in at runtime. That ended up
failing as well:
%strings /usr/local/bin/xcompmgr | grep libXdamage
libXdamage.so.1
%strings /usr/local/bin/xcompmgr | grep libXcomposite
libXcomposite.so.1
%strings /usr/local/bin/xcompmgr | grep libXfixes
libXfixes.so.1
%ll /usr/X11R6/lib/libXdamage.so.1
-rwxr-xr-x 1 root wheel 9098 Jul 6 05:37 /usr/X11R6/lib/libXdamage.so.1*
%ll /usr/X11R6/lib/libXcomposite.so.1
-rwxr-xr-x 1 root wheel 8907 Jul 6 05:35
/usr/X11R6/lib/libXcomposite.so.1*
%ll /usr/X11R6/lib/libXfixes.so.1
-rwxr-xr-x 1 root wheel 18575 Jul 6 05:35 /usr/X11R6/lib/libXfixes.so.1*
%setenv LD_LIBRARY_PATH /usr/X11R6/lib
%/usr/local/bin/xcompmgr
No composite extension
Can anyone point me to some docs on getting these extensions loaded?
_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Date: Fri Jul 16 09:37:25 2004
Subject: [Xorg] future of DRI DDX
Message-ID: <a728f9f904071609303bd3f09c@mail.gmail.com>
Is it worth continuing to support a separate DDX tree for the DRI? In
my opinion, it would be easier for the DRI to just use XORG for DDX.
Any thoughts/opinions one way or another? I know idr may have some
issues with a different tree.
Alex
Date: Fri Jul 16 09:51:21 2004
Subject: [Xorg] xcompmgr
In-Reply-To: <BAY19-F181pyLosv8r80004c489@hotmail.com>
References: <BAY19-F181pyLosv8r80004c489@hotmail.com>
On Fri, 2004-07-16 at 09:22, Joe L. wrote:
> I've been trying to get xcompmgr to start up, but it seems that it can't
> figure out how to interface the fixes, damage or composite extensions.
>
> >From the Xserver compile HOWTO on freedesktop.org, it seems as though the
> extensions don't require a line in /etc/X11/xorg.conf as certain other
> modules do. If it does, the option is hidden pretty well -- I've been
> googling for hours for examples of xorg.conf files that load damage or
> composite extensions. I also tried lines similar to:
There is no support for the extensions necessary to use a compositing
manager in X.Org's X Server. This is on the top of our list for the
next release. The "XServer install howto" is for the xserver
repository, which has the kdrive server, which does have the extensions.
--
From Martin.vGagern at gmx.net Fri Jul 16 11:04:00 2004
From: Martin.vGagern at gmx.net (Martin von Gagern)
Date: Fri Jul 16 11:25:25 2004
Subject: [Xorg] Fontserver in Autotooled KDrive
Message-ID: <40F81890.7060609@gmx.net>
Hello!
I hope that this is the right place for this question. With all those
different XServers around I'm getting a bit confused.
I'm tryiung to use the autotooled version of KDrive via CVS as described
on: http://www.freedesktop.org/Software/xserver
I have the following X libs:
Xproto, XExtensions, FixesExt, Xau, xtrans, Xdmcp, X11 (configured with
--disable-ipv6 and --disable-unix-transport), Xfixes, Xfont, Xext,
Render, Xrender, Randr, Xrandr, CompositeExt, Xcomposite, PanoramiXExt,
xkbfile, DamageExt, Xdamage, ResourceExt
xserver itself is configured:
--enable-xkb --enable-dri --disable-unix-transport --disable-ipv6
I'm using the Xvia binary in a small embedded OS. When I set
"-fp tcp/aaa.bbb.ccc.ddd:7100" I get "Could not init font path element",
although I can get a TCP connection to this font server.
How can I get my font server to work? Am I missing some Libraries or
configuration options?
I found the poorly documented --with-fc option in Xfont, but when I set
this I get unresolved references, e.g. "_FontTransGetConnectionNumber",
for which grep can find no implementation in the whole CVS working
directory of xlibs or xserver/xserver. Where does this come from?
Greetings,
Martin
-------------- next part --------------
Name: signature.asc
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/16c7f419/signat
ure.pgp
From idr at us.ibm.com Fri Jul 16 11:41:11 2004
Date: Fri Jul 16 11:42:20 2004
Subject: [Xorg] future of DRI DDX
In-Reply-To: <a728f9f904071609303bd3f09c@mail.gmail.com>
References: <a728f9f904071609303bd3f09c@mail.gmail.com>
Message-ID: <40F82147.7090102@us.ibm.com>
Alex Deucher wrote:
> Is it worth continuing to support a separate DDX tree for the DRI? In
> my opinion, it would be easier for the DRI to just use XORG for DDX.
> Any thoughts/opinions one way or another? I know idr may have some
> issues with a different tree.
That shouldn't be a problem. I can't even remember when the last time I
made a change to a DDX driver was. I was more concerned about the GLX
code (both client and server). Although I haven't done anything for the
past few weeks, I do a fair amount of work in that area.
From Jim.Gettys at hp.com Fri Jul 16 18:08:43 2004
From: Jim.Gettys at hp.com (Jim Gettys)
Date: Fri Jul 16 18:25:55 2004
Message-ID: <1090026523.5681.12.camel@linux.site>
>
> In the longer term it might also be worth switching to a better
> emulator. The Qemu core is much much faster and also more accurate in
> its emulation functions - eg it can run the C&T 655xx BIOS while x86emu
> fails to do this. The core is LGPL however so I'm not sure how well that
> fits Xorg policy.
>
IMHO, if Qemu is/can be a true LGPL library, it could be used in principle
(just as we use glibc on platforms that use glibc).
What is clearly an insurmountable problem is GPL code/libraries;
there binary commercial drivers get in the way due to aggregation,
a fact of life that while I'm not happy about, is one we can't deal
with...
Given the investments many people/organizations have made in the X code
base, we must be careful that what we do preserves the aggregate
licensing that they contributed to in the first place; ex-post-facto
changes in what they can do with code to which they may have proprietary
extensions to would only encourage forks.
- Jim
Date: Fri Jul 16 19:41:14 2004
Subject: [Xorg] "long long" and "unsigned long long" in xc/ tree...
<40F1C32A.2B680B99@nrubsig.org>
Message-ID: <E1BlemK-0004OW-OZ@evo.keithp.com>
Around 0 o'clock on Jul 12, Roland Mainz wrote:
> I'd like to add some code which uses
> |long long| _everywhere_ and cannot be easily modified to work without
> it...
I'm also planning on using 64 and 128 bit arithmetic in cairo to support
precise tesselation. To do this, I've implemented multi-precision
arithmetic for platforms which don't support these types natively.
Please check out the 'cairo_u128' module available in my CVS repository
for the proposed interface; suggested changes would be welcome. Of
course, the function calls in the interface revert to macros on systems
which support the datatypes natively.
http://keithp.com
holds a pointer to the appropriate CVS module.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/0badf496/attach
ment.pgp
Date: Fri Jul 16 20:20:27 2004
<16626.31376.625651.885331@xf11.fra.suse.de>
Message-ID: <E1BlfkL-0004Sk-DY@evo.keithp.com>
> We are talking about different things here. If code in user land locks up
> the bus the same code in the kernle will certainly have the same effect.
> It certainly will not just produce a 'benign oops'.
I think we're just agreeing that it doesn't matter where the code runs,
the results will be the same.
The operations that need to be run in kernel mode are those which interact
with other operations within the kernel or where kernel services can make
the code safer -- like the ability to ensure that certain pages are in
physical memory or the ability to lock out interrupts temporarily. And, of
course, sometimes it's hugely faster to run some code in kernel mode.
I don't think any of this is true of video mode selection code, at least
not on cards that I'm familiar with. But, I certainly wouldn't proscribe
certain device driver architectures at this point; it may well be
necessary for some cards to have more kernel-level interactions.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/452dfbac/attach
ment.pgp
Date: Fri Jul 16 20:25:24 2004
hardware...
In-Reply-To: Your message of "Mon, 12 Jul 2004 13:16:54 BST."
Message-ID: <E1Blfox-0004TC-7d@evo.keithp.com>
Around 13 o'clock on Jul 12, Alan Cox wrote:
> It isnt that simple because in many cases the scaling and decoding
> can be a single pass more efficiently. Its hard to gauge without someone
> putting a really good scaler in X (not the X image extension stuff!)
"really good" is an impractical basis for a standard X extension; different
applications make different speed/quality tradeoffs. The advantage of
hardware overlay scalers is that they (at least in my limited experience)
are significantly better than reasonably performant software (and "free"
from the CPU's perspective).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/2d7f3603/attach
ment.pgp
Date: Fri Jul 16 20:30:11 2004
In-Reply-To: Your message of "Mon, 12 Jul 2004 07:58:51 PDT."
<40F2A72B.6060304@sun.com>
Message-ID: <E1Blftj-0004UL-Hm@evo.keithp.com>
Around 7 o'clock on Jul 12, Alan Coopersmith wrote:
> (Are there any other bits that are separately maintained
> that need to be brought up to date? Do we need to upgrade fontconfig
> to the 2.2.3 release Keith just put out?)
Yes, we need to update fontconfig; releases along the 2.2 path are only
bugfixes, and the 2.2.3 release solves some FreeType compatibility issues
along with fixing a couple of important bugs.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/6d18c7fe/attach
ment.pgp
Date: Fri Jul 16 20:34:18 2004
hardware...
Message-ID: <E1Blfxg-0004V1-MS@evo.keithp.com>
> No, I mean: Which "side" paints the color key ? The Xv implementation in
> the Xserver or the X client ?
Typically, the X server paints the key. The client can ask that it be
allowed to paint the key if it wants, but I've never seen any app do that.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040716/272b2b0b/attach
ment.pgp
From thomas at winischhofer.net Fri Jul 16 20:49:32 2004
Date: Fri Jul 16 20:56:34 2004
hardware...
In-Reply-To: <E1Blfxg-0004V1-MS@evo.keithp.com>
References: <E1Blfxg-0004V1-MS@evo.keithp.com>
Message-ID: <40F8A1CC.8040107@winischhofer.net>
> Around 20 o'clock on Jul 12, Roland Mainz wrote:
>
>
>>No, I mean: Which "side" paints the color key ? The Xv implementation in
>>the Xserver or the X client ?
>
>
> Typically, the X server paints the key. The client can ask that it be
> allowed to paint the key if it wants, but I've never seen any app do that.
Xine does it that way. It disables automatic painting of the colorkey
(if supported by the respective driver) and paints the colorkey itself.
Point being subtitles which can more easily be done by "skipping" pixels
in the colorkey.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net/
From vektor at dumbterm.net Fri Jul 16 21:24:22 2004
Date: Fri Jul 16 21:40:43 2004
hardware...
In-Reply-To: <40F8A1CC.8040107@winischhofer.net>
<40F8A1CC.8040107@winischhofer.net>
Message-ID: <20040717042422.GE5152@dumbterm.net>
Thomas Winischhofer (thomas@winischhofer.net):
> >
> > Typically, the X server paints the key. The client can ask that it
> > be allowed to paint the key if it wants, but I've never seen any app
> > do that.
>
> Xine does it that way. It disables automatic painting of the colorkey
> (if supported by the respective driver) and paints the colorkey
> itself. Point being subtitles which can more easily be done by
> "skipping" pixels in the colorkey.
Unfortunately they sometimes leave it shut off, meaning that other
applications seem to have to check whether it's true. At least, I'm
now getting bug reports about my app losing video in obscured portions
since we only paint the colour key on map. . .
Anyway, point being that tvtime will in the next version always paint
the colour key to avoid this problem. :)
-Billy
Date: Fri Jul 16 22:12:47 2004
In-Reply-To: <200407160110.17664.bart@verwilst.be>
<200407160110.17664.bart@verwilst.be>
Hash: SHA1
On Thursday 15 July 2004 19:10, Bart Verwilst wrote:
> On Friday 16 July 2004 00:56, you wrote:
> || I believe it was merged with DRI merge a few weeks back.
> ||
> || Alex
>
> Sweet! Great to hear this :)
> So, will that merge be in 6.7.1? Or only in 6.8 or something? :$
Whatever the next release is numbered, IGP DRI support will be in.
- - ajax
iD8DBQFA+Lz3W4otUKDs0NMRAiYlAKCJt8kRzuBVatJ6HiTh0Pf7falv8wCfWT2n
NpJQbvrHze1Df/NOFYP1xnU=
=sUdk
From bart at verwilst.be Sat Jul 17 04:30:55 2004
Date: Sat Jul 17 04:31:00 2004
<200407160110.17664.bart@verwilst.be>
<200407170145.29533.ajax@nwnk.net>
Message-ID: <40F90DEF.80003@verwilst.be>
Adam Jackson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Thursday 15 July 2004 19:10, Bart Verwilst wrote:
>
>
>>On Friday 16 July 2004 00:56, you wrote:
>>|| I believe it was merged with DRI merge a few weeks back.
>>||
>>|| Alex
>>
>>Sweet! Great to hear this :)
>>So, will that merge be in 6.7.1? Or only in 6.8 or something? :$
>>
>>
>
>Whatever the next release is numbered, IGP DRI support will be in.
>
>
Thanks a lot! This is GREAT news :)
Bart
From footourist at gmail.com Sat Jul 17 05:09:23 2004
From: footourist at gmail.com (Hagbard Celine)
Date: Sat Jul 17 09:09:27 2004
Subject: [Xorg] debrix and composite
Message-ID: <2d429e9d040717050946c8f75d@mail.gmail.com>
Hello,
I've downloaded debrix using the instruction on debrix.freedesktop.org, so I sup
pose I've the very latest version.
The first problem is during the configure: it cannot find some extension/library
such as xdcmp.pc, I've then set the variable PKG_CONFIG_PATH pointing at /opt/f
do/lib/pkgconfig which is there from a previous kdrive compiling attempt (succes
ful) and the configure go well.
Is this right?
Anyway let's face the real problem: when I try to compile with --enable-composit
e I get the following error:
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../Xext -I../render -I../randr
-I../xfixes -I../composite -I../mi -I../miext/damage -I../miext/shadow -I../fb
-I../Xi -I../hw/xorg/include -I../hw/xorg/common -I../hw/xorg/os-support -I../hw
/xorg/os-support/bus -I../os -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing
-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_XOPE
N_SOURCE -D_BSD_SOURCE -DXTHREADS -DXUSE_MTSAFE_API -DDFLT_XKB_CONFIG_ROOT="/usr
/X11R6/lib/X11/xkb" -I/opt/fdo/include -I/opt/fdo/include/X11/fonts -I/opt/fdo/i
nclude/X11/Xtrans -DDEFAULT_MODULE_PATH=\"/opt/fdo/lib/xorg/modules/drivers\"
-DDEFAULT_LOGPREFIX=\"/opt/fdo/var/log/Xorg.\" -DXF86CONFIGFILE=\"/opt/fdo/etc/x
org.conf\" -DXKB_BASE_DIRECTORY=\"/opt/fdo/lib/xkb\" -g -O2 -MT fbwindow.o -MD -
MP -MF ".deps/fbwindow.Tpo" -c -o fbwindow.o fbwindow.c; \
then mv -f ".deps/fbwindow.Tpo" ".deps/fbwindow.Po"; else rm -f ".deps/fbwindow.
Tpo"; exit 1; fi
fbwindow.c: In function `fbCopyWindow':
fbwindow.c:142: error: `pPixmap' undeclared (first use in this function)
fbwindow.c:142: error: (Each undeclared identifier is reported only once
fbwindow.c:142: error: for each function it appears in.)
make[1]: *** [fbwindow.o] Error 1
make[1]: Leaving directory `/home/dasnake/freedesktop.org/debrix--devel--0.1--pa
tch-4/fb'
At this time I've looked into the source code (fb/fbwindow.c) and I found:
// XXX DS PixmapPtr pPixmap = fbGetWindowPixmap (pWin);
near the error.
I've tryed to uncomment that and the fb part get compiled, but then:
-I../xfixes -I../composite -I../mi -I../miext/damage -I../damagext -I../miext/s
hadow -I../fb -I../Xi -I../hw/xorg/include -I../hw/xorg/common -I../hw/xorg/os-s
upport -I../hw/xorg/os-support/bus -I../os -Wall -Wpointer-arith -Wstrict-protot
ypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-al
iasing -D_XOPEN_SOURCE -D_BSD_SOURCE -DXTHREADS -DXUSE_MTSAFE_API -DDFLT_XKB_CON
FIG_ROOT="/usr/X11R6/lib/X11/xkb" -I/opt/fdo/include -I/opt/fdo/include/X11/font
s -I/opt/fdo/include/X11/Xtrans -DDEFAULT_MODULE_PATH=\"/opt/fdo/lib/xorg/modu
les/drivers\" -DDEFAULT_LOGPREFIX=\"/opt/fdo/var/log/Xorg.\" -DXF86CONFIGFILE=\"
/opt/fdo/etc/xorg.conf\" -DXKB_BASE_DIRECTORY=\"/opt/fdo/lib/xkb\" -g -O2 -MT co
mpalloc.o -MD -MP -MF ".deps/compalloc.Tpo" -c -o compalloc.o compalloc.c; \
then mv -f ".deps/compalloc.Tpo" ".deps/compalloc.Po"; else rm -f ".deps/compall
oc.Tpo"; exit 1; fi
In file included from compalloc.c:28:
compint.h:47:26: damageextint.h: No such file or directory
compalloc.c: In function `compRedirectWindow':
compalloc.c:94: warning: passing arg 5 of `DamageCreate' from incompatible point
er type
compalloc.c:94: error: too few arguments to function `DamageCreate'
compalloc.c: In function `compRedirectSubwindows':
compalloc.c:297: warning: implicit declaration of function `DamageExtSetCritical
'
make[1]: *** [compalloc.o] Error 1
tch-4/composite'
Ok, I've searched damageextint.h and found it in damageext dir, then added a -I
line to the Makefile to let include that dir and:
-I../xfixes -I../composite -I../mi -I../miext/damage -I../damageext -I../miext/
shadow -I../fb -I../Xi -I../hw/xorg/include -I../hw/xorg/common -I../hw/xorg/os-
support -I../hw/xorg/os-support/bus -I../os -Wall -Wpointer-arith -Wstrict-proto
types -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-a
liasing -D_XOPEN_SOURCE -D_BSD_SOURCE -DXTHREADS -DXUSE_MTSAFE_API -DDFLT_XKB_CO
NFIG_ROOT="/usr/X11R6/lib/X11/xkb" -I/opt/fdo/include -I/opt/fdo/include/X11/fon
ts -I/opt/fdo/include/X11/Xtrans -DDEFAULT_MODULE_PATH=\"/opt/fdo/lib/xorg/mod
ules/drivers\" -DDEFAULT_LOGPREFIX=\"/opt/fdo/var/log/Xorg.\" -DXF86CONFIGFILE=\
"/opt/fdo/etc/xorg.conf\" -DXKB_BASE_DIRECTORY=\"/opt/fdo/lib/xkb\" -g -O2 -MT c
ompalloc.o -MD -MP -MF ".deps/compalloc.Tpo" -c -o compalloc.o compalloc.c; \
then mv -f ".deps/compalloc.Tpo" ".deps/compalloc.Po"; else rm -f ".deps/compall
oc.Tpo"; exit 1; fi
compalloc.c: In function `compRedirectWindow':
compalloc.c:94: warning: passing arg 5 of `DamageCreate' from incompatible point
er type
compalloc.c:94: error: too few arguments to function `DamageCreate'
make[1]: *** [compalloc.o] Error 1
tch-4/composite'
Uhmm, ok I stopped here.
I wonder: is the composite support broken? Or I'm wrong somewhere?
Thanks,
Hagbard
Date: Sat Jul 17 09:14:02 2004
In-Reply-To: <40F59F5C.7000409@bitplanet.net>
<40F59F5C.7000409@bitplanet.net>
Hash: SHA1
On Wednesday 14 July 2004 17:02, Kristian H?gsberg wrote:
> > Dang. I think we got a partially munged XAA when we branched. Any
> > chance one of the other XAA options is the culprit?
>
> I think it's missing the SHAPE extension. I get similar but slightly
> different artifacts for the round corners, and a lot of
>
> Xlib: extension "SHAPE" missing on display ":1.0".
Do you have a Load "extmod" line in your xorg.conf?
- - ajax
iD8DBQFA+Vf2W4otUKDs0NMRAiIcAKDJ0yRwm2YtCHSKo1bxfsauipVxwACfVEtD
78jrqt/pmdguWOjzAWUcO7w=
=+h2S
Date: Sat Jul 17 09:27:57 2004
Subject: [Xorg] debrix and composite
In-Reply-To: <2d429e9d040717050946c8f75d@mail.gmail.com>
References: <2d429e9d040717050946c8f75d@mail.gmail.com>
Hash: SHA1
On Saturday 17 July 2004 08:09, Hagbard Celine wrote:
> Hello,
>
> I've downloaded debrix using the instruction on debrix.freedesktop.org, so
> I sup pose I've the very latest version.
> The first problem is during the configure: it cannot find some
> extension/library such as xdcmp.pc, I've then set the variable
> PKG_CONFIG_PATH pointing at /opt/f do/lib/pkgconfig which is there from a
> previous kdrive compiling attempt (succes ful) and the configure go well.
> Is this right?
Yes.
> I wonder: is the composite support broken? Or I'm wrong somewhere?
Yes (it's broken).
- - ajax
iD8DBQFA+Vs4W4otUKDs0NMRAoCDAJ0XZASYRIBklsc6SmWCLe0fW85aoQCfQrW1
KaQInqMg6p963ZdjpS82EAs=
=bGIh
From qbast at go2.pl Sat Jul 17 13:55:04 2004
Date: Sat Jul 17 14:17:42 2004
Dnia ?ro 14. lipca 2004 06:25, Jesse Barnes napisa?:
> Does it work if you apply the patch and enable it?
>
It doesn't work for me. I checked it with trident driver (for now available
from my tla archive: qbast at go2.pl--2004 http://arch.hypair.net/archives ,
but Daniel said he will merge it soon). Server starts almost ok (vesa bios is
not detected - see log: http://arch.hypair.net/logs/Xorg.log.bad) and works.
But when I kill it screen goes blank and only option is reboot.
When I try enabling x86emu with original cflags from Daniel's repository
(-D_PC -D_VM86_LINUX) it works better - detects vesa bios but fails at ddc
transfer (see http://arch.hypair.net/logs/Xorg.log) - and no problems after
killing xserver.
From jbarnes at engr.sgi.com Sat Jul 17 14:26:14 2004
Date: Sat Jul 17 14:26:21 2004
<200407172255.05051.qbast@go2.pl>
On Saturday, July 17, 2004 4:55 pm, Jakub Stachowski wrote:
> It doesn't work for me. I checked it with trident driver (for now available
> from my tla archive: qbast at go2.pl--2004 http://arch.hypair.net/archives
> , but Daniel said he will merge it soon). Server starts almost ok (vesa
> bios is not detected - see log: http://arch.hypair.net/logs/Xorg.log.bad)
> and works. But when I kill it screen goes blank and only option is reboot.
> When I try enabling x86emu with original cflags from Daniel's repository
> (-D_PC -D_VM86_LINUX) it works better - detects vesa bios but fails at ddc
> transfer (see http://arch.hypair.net/logs/Xorg.log) - and no problems after
> killing xserver.
Doesn't look like we'll be able to unconditionally use the emulator then. I
probably won't have time to throw together an autodetection function for
configure.ac until after the summit and OLS, but I should be able to do it
afterwards.
Jesse
From seb.bel at sympatico.ca Sat Jul 17 19:52:47 2004
From: seb.bel at sympatico.ca (Seb)
Date: Sat Jul 17 20:56:55 2004
Subject: [Xorg] dri changes during merge process..?
Message-ID: <40F9E5FF.4090509@sympatico.ca>
Hello,
I've been spending the last couple of days trying to find an answer to
this, and have in fact found several different reasons etc, most ending
up with: nothing you can do.
The specific problem is (in my case) with a radeon r350 card and ati's
binary driver, and the xorg server.
As many people an example of the problem is running glxinfo spits out
"name of display: :0.0" then stops and sits there, if dri is enabled in
the xorg.conf file while using the fglrx drivers (3.9).
The conclusions I have found about this relate to the dri merge event.
Obviously nothing can be done about the drivers from ati until they put
new ones out.
What I am wondering is if there has been any attempt to backport
whatever was changed in the dri code back to whatever it was at the
point where the ati drivers did work (while still being able to use the
xorg's server.. i'd hate to have to move back to xfree 4.3, hassle and
all that). Certainly there are enough people out there with ati's that
would appreciate being able to use 3d in dri... unless there already is
a way to get it to work that I just didn't stumble upon... to warrent
some kind of backport or interface or something on the dri code...
That is, of course.. if this is the right list to address this issue
with.. seemed to be on the months of emails i went through looking for
any hints.
Seb
From sstubbs at shout.net Sun Jul 18 15:25:33 2004
From: sstubbs at shout.net (The Other)
Date: Sun Jul 18 15:52:26 2004
Subject: [Xorg] Duplicate Symbol BitOrderInvert
Message-ID: <opsbctwvcdt414r7@mailhost.shout.net>
Hello All,
In my xorg.conf.new file, under the Section "Module", while trying
to Load "freetype"
I get this error in the /var/log/Xorg.0.log, as printed here:
-------------------------------------------------------------
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/lfs:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for
inet6
Build Operating System: Linux 2.6.4-ck2 i686 [ELF]
Current Operating System: Linux lfs 2.6.4-ck2 #3 Sun Jul 11 08:09:42
CDT 2004 i686
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jul 18 16:04:07 2004
(++) Using config file: "xorg.conf.new"
(==) ServerLayout "X.org Configured"
(**) FontPath set to
"/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/,/usr/X11R6/lib/X11
/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/us
r/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/"
---snip---
(II) Loading extension XFree86-DGA
(II) Loading extension FontCache
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="X.Org Foundation"
(II) Loading extension GLX
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Loading extension XFree86-DRI
(II) LoadModule: "record"
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="X.Org Foundation"
(II) Loading extension RECORD
(II) LoadModule: "xtrap"
(II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a
(II) Module xtrap: vendor="X.Org Foundation"
(II) Loading extension DEC-XTRAP
(II) LoadModule: "speedo"
(II) Loading /usr/X11R6/lib/modules/fonts/libspeedo.a
(II) Module speedo: vendor="X.Org Foundation"
(II) Loading font Speedo
(II) LoadModule: "freetype"
(II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.a
Duplicate symbol BitOrderInvert in
/usr/X11R6/lib/modules/fonts/libfreetype.a:ftmodule.o
Also defined in (built-in)
Fatal server error:
Module load failure
------------------------------------------------------------------
I've installed FreeType-2.1.7 from the tarball.
I have no clue where to look for "Also defined in (built-in)".
When I comment out the line "Load freetype" in the xorg.conf.new
file, the X system comes up without problems.
Unfortunately, the window manager I wish to use (IceWM 1.2.14)
insists on FreeType being available.
Ideas?
Thanks All,
Stephen Stubbs
Date: Mon Jul 19 01:37:18 2004
hardware...
In-Reply-To: thomas@winischhofer.net wrote on Saturday,
17 July 2004 at 05:49:32 +0200
<40F8A1CC.8040107@winischhofer.net>
> > Around 20 o'clock on Jul 12, Roland Mainz wrote:
> >
> >
> >>No, I mean: Which "side" paints the color key ? The Xv implementation in
> >>the Xserver or the X client ?
> >
> >
> > Typically, the X server paints the key. The client can ask that it be
> > allowed to paint the key if it wants, but I've never seen any app do that.
>
> Xine does it that way. It disables automatic painting of the colorkey
> (if supported by the respective driver) and paints the colorkey itself.
> Point being subtitles which can more easily be done by "skipping" pixels
> in the colorkey.
>
A few drivers allow to disable autopainting by setting an XV
attribute. Which is only an optional cludge. In any case the
default behavior is to do the autopainting in the driver.
In fact a color key is a hardware dependent feature. Exposing
it to the client may proof to be short sighted. It would probably
make more sense to allow the client to pass information on
'undisplayable' areas as a bitmap and let the driver deal with
this.
Egbert.
From Jim.Gettys at hp.com Mon Jul 19 05:58:19 2004
Date: Mon Jul 19 05:58:44 2004
In-Reply-To: <20040712082239.GN12023@fooishbar.org>
<20040712082239.GN12023@fooishbar.org>
On Sun, 2004-07-11 at 21:22, an unknown sender wrote:
> On Sun, Jul 11, 2004 at 04:16:59PM +0300, Ely Levy wrote:
> > And what about the move to XCB?
> > By their page I uderstand they are preety much done,
> > is there a general time table? or what need to be done?
>
> XCL is incomplete, and the X server doesn't need to change; the libs
> just need to be added.
And we need *a lot* of testing in the real world... Hopefully we'll
be able to start the general testing process reasonably soon.
Remember, this is a complete rewrite of the core insides of Xlib
(which really needs it), but it certainly is needed...
- Jim
Date: Mon Jul 19 06:41:46 2004
hardware...
<16635.34815.287101.306419@xf11.fra.suse.de>
Message-ID: <E1BmYNy-0004YE-1a@evo.keithp.com>
> It would probably
> make more sense to allow the client to pass information on
> 'undisplayable' areas as a bitmap and let the driver deal with
> this.
Easier to just map an ARGB window on top and composite it with the video
image. That works quite nicely today and doesn't require any new
semantics anywhere.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040719/121ba12c/attach
ment.pgp
Date: Mon Jul 19 07:02:56 2004
hardware...
In-Reply-To: keithp@keithp.com wrote on Monday, 19 July 2004 at 06:40:53 -0700
<E1BmYNy-0004YE-1a@evo.keithp.com>
>
>
> > It would probably
> > make more sense to allow the client to pass information on
> > 'undisplayable' areas as a bitmap and let the driver deal with
> > this.
>
> Easier to just map an ARGB window on top and composite it with the video
> image. That works quite nicely today and doesn't require any new
> semantics anywhere.
>
The FillKeyHelper() doesn't know anything about composite so I'm not
sure if it will do the right thing.
It may be very interestiong to see a composite window mapped on top
of a video. If color keying is used it is composited with color key
- not the video image. When the color value of the pixel changes the
video will no longer be displayed but the composition of color key
and window content mapped on top.
Today you can already see this with a transparent (soft) cursor mapped on
top of a video. It works in a sense that it doesn't produce complete junk
but doesn't look like what one may expect.
We may be able to fix this if we display the video as a 3D texture
as most modern chips support it. In fact some drivers can already do
that.
Egbert.
From sandmann at daimi.au.dk Mon Jul 19 13:22:33 2004
Date: Mon Jul 19 13:28:55 2004
Subject: [Xorg] Extension extension
Message-ID: <ye8vfgj21di.fsf@horse05.daimi.au.dk>
So I have been thinking about an extension-extension to reduce the
number of roundtrips during startup. I have discussed it a bit with
Adam Jackson (ajax on IRC).
Current state of affairs
========================
Clients initializes a lot of extensions and we should probably
expect them to initialize more in the future. Here is a list of
some popular extensions and the data clients immediately ask for:
BIG-REQUESTS
Everybody loves this extension because XLib initializes it
automatically and then immediately issues a BigReqestsEnable request.
MIT-SHM:
Clients immediately sends MitShmQueryVersion which returns the version
XInputExtension
Two additional round-trips: GetExtensionVersion and ListInputDevices
RENDER:
QueryVersion , QueryPictFormats

XKB
XkbUseExtension
So it seems the adiitional data falls in two categories:
GetVersionNumber
and

QuerySomeData (which doesn't take any arguments)
Generally the data that clients query for (formats, devices, etc) is
needed before the client can go on using the extension.
So that's generally two to three round-trips per extension. This
write-up looks into ways of reducing that. There are several
possibilities, ranging from no server changes to many server changes:
Just Improve The Client Side
============================
There are things that could be done on the client side without any
server changes at all:
- Xlib
It would be possible to add a new call
XQueryManyExtensions (Display *display,
char **names,
int n_names,
Bool *present)
to XLib that would send a lot of QueryExtension and return a list of
booleans indicating whether the extensions were present. In addition,
you could also imagine an
XQueryVersions (char **names, int n_names,
int *majors, int *minors)
that would return the version numbers of extensions that have them.
However all the extension specific data would still have to be queries
per extension, so the number of round-trips would still depend on the
number of extensions.
Within the framework of Xlib I don't think there is much more that can
be done without turning Xlib into an ad-hoc version of XCB.
- XCB
With XCB, we can get down to three round-trips total:
- Initial handshake
- Send many QueryExtension
- Send many QueryVersion, send many QueryData requests
Note that some of the queries for extension specific data might only be
available with certain versions of the extension. That doesn't have to
stop us from sending them; the client should just be prepared to handle
BadRequest errors.
If handling BadRequest errors is deemed too ugly, XCB can only get us
down to four round trips.
Adding a New META Extension
===========================
Xlib
----
Assuming we will still use Xlib, a new extension could improve on XCB
by one roundtrip. The extension could include a new request
MetaQueryManyExtensions
List of names
->
List of ExtensionData
where ExtensionData is
CARD32 MajorVersion
CARD32 MinorVersion
CARD32 DataLength
CARD8 extension data
The extension data is specific to each extension. For example the RENDER
extension could send the list of supported formats. There would be a
client side API
struct XMetaExtensionData
{
char *name;
int major;
int minor;
void *data;
}
XMetaQueryManyExtensions (char **names, int n_names,
XMetaExtensionData *ext_data);
XMetaFreeExtensionData (XMetaExtensionData *data);
And each extension would add calls like:
PictFormat *
XRenderGetPictFormats (XMetaExtensionData *data);
With this we could get down to three roundtrips:
- Initial handshake
- QueryExtension
- MetaQueryExtensio
The big drawback here is that the META extension would have to know
about all other extensions, and all other extensions would have to
document what data they would send and how to interpret it. Also the
client side API is clumsy.
A different scheme, requiring more changes to the X server is:
MetaQueryExtension
STRING8 name
CARD8 major_opcode
->
BOOL present
CARD8 first_event
CARD8 first_error
CARD32 major_version
CARD32 minor_version
Error:
BadOpcode
Ie., the client allocates the major_opcode for the extension. This would
have the big advantage that the client could then send extension
requests immediately provided it would be prepared to handle
BadRequests.
With XCB as the client API we would get down to three roundtrips:
- Initial handshake
- QueryExtension (for the META extension)
- MetaQueryExtension + all the extension specific queries
In terms of number of roundtrips this is not an improvement, but the
advantage in terms of elegance and generality is considerable. The
drawback is that substantial server changes would be needed to allow
client allocated major opcodes.
This extension could still be useful with Xlib():
XMetaQueryManyExtensions (char **names, int n_names);
That would send all the QueryExtensions and a lot of common extension
queries. The data returned from those queries would then have to be
cached.
Finally,
Bumping the minor version number of the X protocol
==================================================
The most radical thing to do would be to bump the minor version number
of the X protocol and have the initial handshake include extension
negotiation.
Doing this would bring the number of roundtrips down to one, because
everything the client wanted to know would be in the initial data sent
by the X server.
The drawback here is obvious: a new protocol version is a big thing that
should probably only happen if much other stuff would be fixed.
So, it seems to me that there isn't actaully much to be gained from
creating a new Meta extension. We can't really get below three
roundtrips wihtout changing the protocol, and on the other hand we _can_
get down to three roundtrips with just client side changes.
S?ren
From eta at lclark.edu Mon Jul 19 13:29:27 2004
Date: Mon Jul 19 13:34:42 2004
Subject: [Xorg] Re: i830 driver status..
In-Reply-To: <a728f9f9040719072553e181d1@mail.gmail.com>
References: <Pine.LNX.4.58.0407150820340.17862@skynet>
<a728f9f90407160606172a96c4@mail.gmail.com>
<Pine.LNX.4.58.0407161218080.10003@devel.capslock.lan>
<40FBD895.2060105@tungstengraphics.com>
<a728f9f9040719072553e181d1@mail.gmail.com>
On Mon, 2004-07-19 at 07:25, Alex Deucher wrote:
> On Mon, 19 Jul 2004 15:20:05 +0100, Keith Whitwell
> <keith@tungstengraphics.com> wrote:
> > Mike A. Harris wrote:
> > > On Fri, 16 Jul 2004, Alex Deucher wrote:
> > >
> > >
> > >>Date: Fri, 16 Jul 2004 09:06:26 -0400
> > >>From: Alex Deucher <alexdeucher@gmail.com>
> > >>To: Dave Airlie <airlied@skynet.ie>
> > >>Cc: dri-devel@lists.sourceforge.net
> > >>Content-Type: text/plain; charset=US-ASCII
> > >>X-BeenThere: dri-devel@lists.sourceforge.net
> > >>Subject: Re: i830 driver status..
> > >>
> > >>On Thu, 15 Jul 2004 08:22:42 +0100 (IST), Dave Airlie <airlied@skynet.ie>
wrote:
> > >>
> > >>>Is the i830 driver considered to be dead, should any future work go
> > >>>towards the i915 one?
> > >>>
> > >>>just like to get a semi-official idea? if so we need to import the up to
> > >>>date DDX into the DRI tree and start releasing the snapshots for the i915
> > >>>driver..
> > >>
> > >>Sounds good to me. At this point perhaps we should just not worry
> > >>about updating the DRI tree and just switch to using the XORG tree for
> > >>DDX. it's a lot of hassle to have to maintain both trees and then
> > >>moves changes back and forth. New dri DDX related work can happen on
> > >>a branch maybe. Just a thought...
> > >
> > >
> > > I think it is a great idea if the DRI CVS tree moves into X.org,
> > > either on Xorg CVS head, or on a branch - either would be better
> > > than having so many different repositories to track, and merging
> > > would probably be much smoother also, and could possibly be done
> > > more often as well.
> > >
> > > Please bring this up on the xorg@freedesktop.org list if it
> > > hasn't already (haven't checked my xorg folder). The new release
> > > is looming on the near horizon for late August or thereabouts, so
> > > it would be nice if this change could occur before then.
> >
> > Yes, my hope is now that people will just do their X work on the X.org CVS
> > repository (like regular X developers - the old DRI/X distinction was pretty
> > artificial) and the DRI tree can be archived.
>
> before we archive it, we ought to bring the WIP (savage, mach64,
> virge, etc.) drivers over to a banch in XORG.
I'm thinking maybe we don't want to use a branch. Here's the idea: We
make the DevelDRIDrivers define in imake include all these new,
insecure, not-guaranteeing-backwards-compatibility drivers, and they're
only turned on when we add #define BuildDevelDRIDrivers YES. For the
DDXs of those drivers, we add this to their Imakefile
#if !BuildDevelDRIDrivers
#undef BuildXF86DRI
#endif
Now, no more fighting with branches, merges both directions, etc. We
get to keep saying "These drivers are insecure, we don't guarantee
backwards compatibility," etc. because they're disabled. Our users are
happy that they don't have to learn about checking out branches to get
their drivers. And we can ensure that we continue covering compiling of
both paths in trunk by using the tinderbox.
--
Date: Mon Jul 19 13:48:09 2004
<a728f9f90407160606172a96c4@mail.gmail.com>
<Pine.LNX.4.58.0407161218080.10003@devel.capslock.lan>
<40FBD895.2060105@tungstengraphics.com>
<a728f9f9040719072553e181d1@mail.gmail.com>
<1090268966.986.12.camel@leguin>
Message-ID: <a728f9f90407191341686bb7a7@mail.gmail.com>
On Mon, 19 Jul 2004 13:29:27 -0700, Eric Anholt <eta@lclark.edu> wrote:
>
>
> On Mon, 2004-07-19 at 07:25, Alex Deucher wrote:
> > On Mon, 19 Jul 2004 15:20:05 +0100, Keith Whitwell
> > <keith@tungstengraphics.com> wrote:
> > > Mike A. Harris wrote:
> > > > On Fri, 16 Jul 2004, Alex Deucher wrote:
> > > >
> > > >
> > > >>Date: Fri, 16 Jul 2004 09:06:26 -0400
> > > >>From: Alex Deucher <alexdeucher@gmail.com>
> > > >>To: Dave Airlie <airlied@skynet.ie>
> > > >>Cc: dri-devel@lists.sourceforge.net
> > > >>Content-Type: text/plain; charset=US-ASCII
> > > >>X-BeenThere: dri-devel@lists.sourceforge.net
> > > >>Subject: Re: i830 driver status..
> > > >>
> > > >>On Thu, 15 Jul 2004 08:22:42 +0100 (IST), Dave Airlie <airlied@skynet.ie
> wrote:
> > > >>
> > > >>>Is the i830 driver considered to be dead, should any future work go
> > > >>>towards the i915 one?
> > > >>>
> > > >>>just like to get a semi-official idea? if so we need to import the up t
o
> > > >>>date DDX into the DRI tree and start releasing the snapshots for the i9
15
> > > >>>driver..
> > > >>
> > > >>Sounds good to me. At this point perhaps we should just not worry
> > > >>about updating the DRI tree and just switch to using the XORG tree for
> > > >>DDX. it's a lot of hassle to have to maintain both trees and then
> > > >>moves changes back and forth. New dri DDX related work can happen on
> > > >>a branch maybe. Just a thought...
> > > >
> > > >
> > > > I think it is a great idea if the DRI CVS tree moves into X.org,
> > > > either on Xorg CVS head, or on a branch - either would be better
> > > > than having so many different repositories to track, and merging
> > > > would probably be much smoother also, and could possibly be done
> > > > more often as well.
> > > >
> > > > Please bring this up on the xorg@freedesktop.org list if it
> > > > hasn't already (haven't checked my xorg folder). The new release
> > > > is looming on the near horizon for late August or thereabouts, so
> > > > it would be nice if this change could occur before then.
> > >
> > > Yes, my hope is now that people will just do their X work on the X.org CVS
> > > repository (like regular X developers - the old DRI/X distinction was pret
ty
> > > artificial) and the DRI tree can be archived.
> >
> > before we archive it, we ought to bring the WIP (savage, mach64,
> > virge, etc.) drivers over to a banch in XORG.
>
> I'm thinking maybe we don't want to use a branch. Here's the idea: We
> make the DevelDRIDrivers define in imake include all these new,
> insecure, not-guaranteeing-backwards-compatibility drivers, and they're
> only turned on when we add #define BuildDevelDRIDrivers YES. For the
> DDXs of those drivers, we add this to their Imakefile
>
> #if !BuildDevelDRIDrivers
> #undef BuildXF86DRI
> #endif
>
> Now, no more fighting with branches, merges both directions, etc. We
> get to keep saying "These drivers are insecure, we don't guarantee
> backwards compatibility," etc. because they're disabled. Our users are
> happy that they don't have to learn about checking out branches to get
> their drivers. And we can ensure that we continue covering compiling of
> both paths in trunk by using the tinderbox.
Sounds good to me, however, does that mean there'll have to be lots of
#ifdefs in the code to protect the "experimental" sections from the
"stable" sections in the DDXs? I suppose that wouldn't be too bad.
Alex
>
> --
>
From brian.gabriel at gmail.com Mon Jul 19 12:51:54 2004
From: brian.gabriel at gmail.com (Brian Gabriel)
Date: Mon Jul 19 13:52:06 2004
Subject: [Xorg] Problem compiling X11R6.7.0 on Services for Unix
Message-ID: <3ceb2e6f0407191251e2b65c3@mail.gmail.com>
I am trying to compile X11R6.7.0 on Microsoft Services for Unix
(Internix) 3.5. When I compile with GCC 3.3 I get the following error
message:

cc -o makekeys -O -I../.. -I../../exports/include
-DPOSTLOCALELIBDIR=\"lib\" -DXVENDORNAME='"The
X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' util/makekeys.c
-L/usr/X11R6/lib
H:\SFU\xc\exports\include\X11/X.h(1) : error C2018: unknown character '0x1'
In all of the files in xc\exports\includes\X11 have a couple of
garbage characters in the beginning of the file, this is causing many
errors to be reported, and the build is not successful.
Any help would be greatly appreciated. Thanks,

Brian G
From ajax at nwnk.net Mon Jul 19 14:50:17 2004
Date: Mon Jul 19 15:01:19 2004
In-Reply-To: <a728f9f90407191341686bb7a7@mail.gmail.com>
<1090268966.986.12.camel@leguin>
<a728f9f90407191341686bb7a7@mail.gmail.com>
Hash: SHA1
On Monday 19 July 2004 16:41, Alex Deucher wrote:
> On Mon, 19 Jul 2004 13:29:27 -0700, Eric Anholt <eta@lclark.edu> wrote:
> >
> > I'm thinking maybe we don't want to use a branch. Here's the idea: We
> > make the DevelDRIDrivers define in imake include all these new,
> > insecure, not-guaranteeing-backwards-compatibility drivers, and they're
> > only turned on when we add #define BuildDevelDRIDrivers YES. For the
> > DDXs of those drivers, we add this to their Imakefile
> >
> > #if !BuildDevelDRIDrivers
> > #undef BuildXF86DRI
> > #endif
> >
> > Now, no more fighting with branches, merges both directions, etc. We
> > get to keep saying "These drivers are insecure, we don't guarantee
> > backwards compatibility," etc. because they're disabled. Our users are
> > happy that they don't have to learn about checking out branches to get
> > their drivers. And we can ensure that we continue covering compiling of
> > both paths in trunk by using the tinderbox.
Brilliant!
> Sounds good to me, however, does that mean there'll have to be lots of
> #ifdefs in the code to protect the "experimental" sections from the
> "stable" sections in the DDXs? I suppose that wouldn't be too bad.
We need those anyway, to mask the DRI code off from non-DRI platforms.
- - ajax
iD8DBQFA/EIaW4otUKDs0NMRAnaIAJ9vvJCf7AmHYgzYOFqPA4QRaDO44ACeMWZW
FGG0YM3vcyipfOXgz3hWQ8U=
=ZbIZ
From carl at personnelware.com Mon Jul 19 17:44:11 2004
Date: Mon Jul 19 17:50:32 2004
Subject: [Xorg] i830_video.c:1452: error: `noPanoramiXExtension' undeclared
Message-ID: <1c3d01c46df2$ac85f570$1e01a8c0@cnt496>
building CVS:
+ cd ../../../../../../exports/lib/modules/drivers
+ ln -s ../../../../programs/Xserver/hw/xfree86/drivers/fbdev/fbdev_drv.o .
i830_video.c: In function Ì830PutImage':
function)
i830_video.c:1452: error: (Each undeclared identifier is reported only once
i830_video.c:1452: error: for each function it appears in.)
i830_video.c: In function Ì830DisplaySurface':
function)
make[7]: *** [i830_video.o] Error 1
make[6]: *** [all] Error 2
make[4]: *** [hw/xfree86] Error 2
make[1]: *** [World] Error 2
make: *** [World] Error 2
Anyone
A) want more info
and or
B) know how I can work around it?
Carl K
From krh at bitplanet.net Mon Jul 19 18:43:08 2004
Date: Mon Jul 19 18:45:03 2004
References: <200407131814.10421.jbarnes@engr.sgi.com> <200407140025.14594.jbar
nes@engr.sgi.com> <200407172255.05051.qbast@go2.pl>
Message-ID: <40FC78AC.7010909@bitplanet.net>
Jesse Barnes wrote:
> On Saturday, July 17, 2004 4:55 pm, Jakub Stachowski wrote:
>
>>It doesn't work for me. I checked it with trident driver (for now available
>>from my tla archive: qbast at go2.pl--2004 http://arch.hypair.net/archives
>>, but Daniel said he will merge it soon). Server starts almost ok (vesa
>>bios is not detected - see log: http://arch.hypair.net/logs/Xorg.log.bad)
>>and works. But when I kill it screen goes blank and only option is reboot.
>>When I try enabling x86emu with original cflags from Daniel's repository
>>(-D_PC -D_VM86_LINUX) it works better - detects vesa bios but fails at ddc
>>transfer (see http://arch.hypair.net/logs/Xorg.log) - and no problems after
>>killing xserver.
>
> Doesn't look like we'll be able to unconditionally use the emulator then. I
> probably won't have time to throw together an autodetection function for
> configure.ac until after the summit and OLS, but I should be able to do it
> afterwards.
I have a patch in my archive (also attached for easy review) that adds a
--with-int10={vm86,x86emu,stub} option to configure. I didn't implement
the autodetection you mention, but it should be fairly straightforward.
Also, the patch adds a (simple) check for SYSV_IPC (shmget et al), so
HAVE_SYSV_IPC gets set and xf86shmget() does something useful.
My archive: debrix--krh--0.1 in http://bitplanet.net/arch/2004
Daniel, did you pull the debrix-input-mouse--krh--0.1 and
debrix-input-keyboard--krh--0.1 branches yet? It would be nice to have
these in an upstream archive.
Kristian
-------------- next part --------------
Name: int10.patch
Type: text/x-patch
Size: 3423 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040720/03c59fea/int10-
0001.bin
Date: Mon Jul 19 19:20:30 2004
In-Reply-To: <40FC78AC.7010909@bitplanet.net>
<40FC78AC.7010909@bitplanet.net>
On Monday, July 19, 2004 9:43 pm, Kristian H?gsberg wrote:
> I have a patch in my archive (also attached for easy review) that adds a
> --with-int10={vm86,x86emu,stub} option to configure. I didn't implement
> the autodetection you mention, but it should be fairly straightforward.
> Also, the patch adds a (simple) check for SYSV_IPC (shmget et al), so
> HAVE_SYSV_IPC gets set and xf86shmget() does something useful.
>
> My archive: debrix--krh--0.1 in http://bitplanet.net/arch/2004
>
> Daniel, did you pull the debrix-input-mouse--krh--0.1 and
> debrix-input-keyboard--krh--0.1 branches yet? It would be nice to have
> these in an upstream archive.
Looks great, thanks a lot!
Jesse
From thefowle at wam.umd.edu Mon Jul 19 23:18:16 2004
From: thefowle at wam.umd.edu (Matthew Evan Fowle)
Date: Mon Jul 19 23:50:25 2004
Subject: [Xorg] source of input
Message-ID: <Pine.SOL.4.44.0407200213410.28892-100000@rac3.wam.umd.edu>
i've been trying to write a multi-user window manager, sort of a x2x or
synergy in reverse, but i cannot get off the ground: i am unable to find
any means to detect which input source an input event was
generated with.
my goal is to be able to seperate the different input sources from one
another. so i could have, for example, two mice, each with their own
distinct cursor. i'm willing to implement a crude hack to share a
CorePointer between two "fake" cursors (the "window manager"), but I have
been unable to find any means to differentiate input between the two mice.
if anyone has suggestions for how I can go about finding what physical
device an input event (Motion, keyboard, or otherwise) was generated from,
i would be very much oblidged.
Thank you
Myren
From jserv at linux2.cc.ntu.edu.tw Tue Jul 20 00:20:54 2004
From: jserv at linux2.cc.ntu.edu.tw (jserv@linux2.cc.ntu.edu.tw)
Date: Tue Jul 20 00:33:57 2004
Subject: [Xorg] Fail to run fd.o Xserver
Message-ID: <20040720072054.GA2957@linux2.cc.ntu.edu.tw>
Hello all,
Recently, I cvs update fd.o xserver and rebuilt, but I got into
trouble with the following messages:
$ /tmp2/bin/Xfake :1
Fatal server error:
Cannot establish any listening sockets - Make sure an X server isn't
already running
I followed the instructions of XserverInstallGuide[1], and configured
with the options:
$ cat ../xlibs-src/conf-X11
sh configure \
--prefix=/tmp2 \
--disable-unix-transport \
--disable-tcp-transport \
--disable-ipv6 \
--enable-xthreads \
--disable-xcms \
--enable-xlocale \
--enable-xkb \
--without-xcb
$ cat conf-xserver
sh configure \
--prefix=/tmp2 \
--with-fontpath=/tmp2/share/fonts \
--enable-composite \
--disable-werror \
--enable-xinput --enable-xkb \
--enable-dri \
--disable-unix-transport \
--disable-tcp-transport \
--disable-ipv6 \
--enable-screensaver \
--disable-xdmcp \
--disable-xdm-auth-1 \
--enable-xorgserver
Also, I can't build xserver with --enable-xkb without
--enable-xorgserver.
However, I did get fd.o xserver working last month, and the above
sequence was here since cvs update. Could anyone give me a hint?
cheers,
Jim Huang
[1] http://xserver.freedesktop.org/Software/XserverInstallGuide
Date: Tue Jul 20 05:27:29 2004
Subject: [Xorg] i830_video.c:1452: error: `noPanoramiXExtension'
undeclared
References: <1c3d01c46df2$ac85f570$1e01a8c0@cnt496>
Message-ID: <1f3001c46e54$26699b60$1e01a8c0@cnt496>
> building CVS:
>
> + cd ../../../../../../exports/lib/modules/drivers
> + ln -s ../../../../programs/Xserver/hw/xfree86/drivers/fbdev/fbdev_drv.o .
> i830_video.c: In function Ì830PutImage':
> i830_video.c:1452: error: `noPanoramiXExtension' undeclared (first use in this
> function)
> i830_video.c:1452: error: (Each undeclared identifier is reported only once
> i830_video.c:1452: error: for each function it appears in.)
> i830_video.c: In function Ì830DisplaySurface':
> i830_video.c:1837: error: `noPanoramiXExtension' undeclared (first use in this
> function)
> make[7]: *** [i830_video.o] Error 1
> make[6]: *** [all] Error 2
> make[4]: *** [hw/xfree86] Error 2
> make[1]: *** [World] Error 2
> make: *** [World] Error 2
>
Above was with #define BuildXinerama NO
I took it out, it built, but when I ran it:
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Jul 20 07:32:45 2004
(EE) I810: Failed to load module "dri" (once-only module, 0)
Fatal server error:
for help.
information.
after 0 requests (0 known processed) with 0 events remaining.
Which I think is why I turned off BuildXinerama.
Carl K
Date: Tue Jul 20 09:07:13 2004
Subject: [Xorg] [ALPHA] Duoview support for mobile savages
Message-ID: <a728f9f904072009071ac18a47@mail.gmail.com>
At long last I've gotten duoview (dualhead) working with my savage IX!
It should also work on MX and Supersavage chips, but I don't have the
hardware to test. My current code is a bit of a hack, basically just 2
viewports into a big framebuffer. There are no safeguards in the code
at the moment. USE AT YOUR OWN RISK! As I'm not (yet) able to change
the framebuffer offset on crtc2, only left of, above, and clone
orientations are supported right now. Configuration notes and support
information as well as a patch and binary are available here:
http://www.botchco.com/alex/new-savage/html/
Full-fledged "regular" multi-head and MergedFB support as well as bug
fixes and new features will be added as I have time.
I want to thank Tim and Austin for their help on this. I could not
have done it with out them.
Enjoy,
Alex
From Soeren.Sandmann at daimi.au.dk Fri Jul 2 13:55:35 2004
From: Soeren.Sandmann at daimi.au.dk (sandmann@redhat.com)
Date: Tue Jul 20 11:35:58 2004
Subject: [Xorg] MMX speedup
Message-ID: <ye8y8m2gmd9.fsf@ec02.daimi.au.dk>
Attached is a patch that speeds up some operations in the Render
extension by using gcc 3.4 MMX intrinsics. A benchmark rendering a
paragraph of component alpha text to a pixmap gave these results on a
1200 MHz laptop with an i830 chip running Fedora Core I:
Unmodified X server and the pixmap in system RAM:
worst rect: 9
with the MMX optimizations:
worst rect: 9
Ie., text rendering is more than twice as fast. The patch includes
improved code for these cases:
Subpixel text:
- (constant color) in (component alpha mask) over 565 destination
- (constant color) in (component alpha mask) over 32bit destination
- (32 bit component alpha) Saturate (32 bit destination)
Regular antialiased text:
- (8 bit alpha) Saturate (8 bit destination)
- (constant color) in (8 bit alpha mask) over 565 destination
- (constant color) in (8 bit alpha mask) over 32bit destination
GdkPixbuf:
- (reversed, non-premultiplied source) over 32bit destination
- (reversed, non-premultiplied source) over 565 destination
Alpha rectangle (e.g., Nautilus selection rectangle):
- (constant color) over 32bit destination
- (constant color) over 565 destination
Solid fill
The code can optionally be compiled to use the pshufw instruction, which
is only available on pentium III.
The patch has a bad hack where it redefines DefaultCCOptions for all of
the framebuffer code. This is clearly not the best way to do it, but I'm
not sure how it could be done otherwise.
Soeren
-------------- next part --------------
Name: mmx.patch
Type: text/x-patch
Size: 15579 bytes
Desc: The patch
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/b927afea/mmx-00
01.bin
-------------- next part --------------
Name: fbmmx.c
Size: 31893 bytes
Desc: fbmmx.c
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/b927afea/fbmmx-
0002.obj
-------------- next part --------------
Name: fbmmx.h
Size: 4796 bytes
Desc: fbmmx.h
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/b927afea/fbmmx-
0003.obj
-------------- next part --------------
Name: render-benchmark.c
Size: 5340 bytes
Desc: The benchmark
Url : http://freedesktop.org/pipermail/xorg/attachments/20040702/b927afea/render
-benchmark-0001.obj
From jplee at astrazeneca.com Tue Jul 20 12:28:58 2004
From: jplee at astrazeneca.com (jplee@astrazeneca.com)
Date: Tue Jul 20 12:34:17 2004
Subject: [Xorg] VFB: problem with unsupported bit depth.
Message-ID: <7AAAA741F386B04390FCD7FB61F9154653E885@usbodmsx01.rd.astrazeneca.ne
t>

Hi,

I hope someone can help me. My sysadmin built and installed xvfb on a
Solaris 5.8 machine. I am tying to access it from a java servlet running
inside
Tomcat 4.1.27, JVM 1.4.1_01-b01. Xvfb was initially started by the Tomcat
user
like so:

/usr/X11R6/bin/Xvfb :1 -screen 0 1280x1024x8 -fbdir /tmp &
My servlet creates a java Frame object and then attempts to create an Image
in it.
Headless mode wouldn't work, due to a conflict with a needed JAR file. I
receive the following
error when I try to associate the screen resource with it:

sun.java2d.InvalidPipeException: Unsupported bit depth: 4
at sun.awt.X11SurfaceData.getSurfaceType(X11SurfaceData.java:424)
at sun.awt.X11GraphicsConfig.getSurfaceType(X11GraphicsConfig.java:116)
at sun.awt.X11SurfaceData.createData(X11SurfaceData.java:284)
at sun.awt.motif.MComponentPeer.initialize(MComponentPeer.java:193)
at sun.awt.motif.MComponentPeer.init(MComponentPeer.java:225)
at sun.awt.motif.MWindowPeer.init(MWindowPeer.java:93)
at sun.awt.motif.MFramePeer.(MFramePeer.java:58)
at sun.awt.motif.MToolkit.createFrame(MToolkit.java:197)
at java.awt.Frame.addNotify(Frame.java:469)
. . .
I tried setting "-pixdepths 4" on the cmd line, but receive the same error.
I am not
prescribing a pixel depth of 4 bpp in my code, so it must have something to
do
with xvfb, or a display driver. Does xvfb use a display driver, or is it the
display driver?
Is there some other setting needed in the build process?

Can someone explain what happens when the X server starts up, what resources
it grabs, etc?

thanks,

jp
-------------- next part --------------
URL: http://freedesktop.org/pipermail/xorg/attachments/20040720/c159828f/attachm
ent.html
Date: Tue Jul 20 13:06:17 2004
In-Reply-To: <20040720072054.GA2957@linux2.cc.ntu.edu.tw>
References: <20040720072054.GA2957@linux2.cc.ntu.edu.tw>
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 20 July 2004 03:20, jserv@linux2.cc.ntu.edu.tw wrote:
> I followed the instructions of XserverInstallGuide[1], and configured
> with the options:
>
> $ cat ../xlibs-src/conf-X11
> sh configure \
> --prefix=3D/tmp2 \
> --disable-unix-transport \
> --disable-tcp-transport \
> --disable-ipv6 \
^^^^^^^^^^^^^^
You just disabled three of the four transports X knows about. Since you=20
probably don't have DECnet support in your kernel (no one does), the server=
=20
will never be able to find a transport to listen on. Thus the "Cannot=20
establish any listening sockets" error.
You need to enable at least one of those, and you'll probably want both uni=
x=20
and tcp.
=2D - ajax
=2D----BEGIN PGP SIGNATURE-----
iD8DBQFA/VGYW4otUKDs0NMRApcpAJ9mBnxOZcne5nks3wzGbOQpld1t8wCg2YMb
2YQKHJYo+2bxq7qXX4dIVL0=3D
=3DWPOi
=2D----END PGP SIGNATURE-----
From tim at birdsnest.maths.tcd.ie Tue Jul 20 13:53:14 2004
From: tim at birdsnest.maths.tcd.ie (Timothy Murphy)
Date: Tue Jul 20 14:31:03 2004
Subject: [Xorg] Prtoblem with X on Sony Picturebook
Message-ID: <200407202153.16589.tim@birdsnest.maths.tcd.ie>
I've been trying for some weeks to get X running properly on my Sony laptop,
under Fedora-2 (and so Xorg).
Under Fedora-1, as under all versions of RedHat previously,
X ran perfectly at 1024x480x16bpp,
but the best I have been able to do with Xorg is 1024x480x8bpp
or 800x375x16bpp.
I reported this as an xorg bugzilla about 6 weeks ago
<http://freedesktop.org/bugzilla/show_bug.cgi?id=718>.
Here is the bugzilla report:
====================================================
Opened: 2004-06-03 20:44
Sony C1VFK Picturebook (notebook) under Fedora-2
Video board: ATI Rage Mobility P/M (Mach 128)
This ran at 1024x480 with 16bpp under Fedora-1 (XFree86)
but it does not appear possible to attain this now.
It runs OK at 1024x480 with 8bpp;
but when run with 16bpp one gets a large black oval
which shrinks to leave a blank white or cream screen.
There seem to be no errors reported in Xorg.0.log .
Several people have reported this failure,
and no-one seems to have found a solution.
====================================================
I've seen no evidence that this has been looked at by anyone,
and I don't have great hope it will be looked at in the near future.
So rather reluctantly I am seeing if I can make sense of it myself.
I say reluctantly because I know very little - effectively nothing - about X.
I have a number of preliminary questions,
which I would be most grateful to get a response to:
(1) Is this a sensible place to send queries of this kind?
Is there anywhere else where one might get help with such a query?
(2) There are several things about /etc/log/Xorg.0.log
which I don't understand.
Again, is there any document that would explain how to interpret
this log file?
For example, there are many entries like
(II) ATI(0): Not using default mode "400x300" (exceeds panel dimensions)
I don't understand how 400x300 can "exceed panel dimensions".
particularly as it later seems to accept
(**) ATI(0): Default mode "640x480": 36.0 MHz, 43.3 kHz, 85.0 Hz
(3) More importantly, probably, where does it get the Default modes it lists?
Are they built into the driver?
I expected to find them somewhere in /usr/X11R8/lib/doc .
(4) How can I tell from this log file what the bpp setting is?
Well, I guess that is enough questions to start with,
though I have several more.
I might mention that I tried using the "ati" driver from FC-1,
but this failed with many undefined variables.
I guess there have been library changes since that version of XFree86.
Any and all suggestions or advice gratefully received.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
From jserv at linux2.cc.ntu.edu.tw Wed Jul 21 00:22:18 2004
From: jserv at linux2.cc.ntu.edu.tw (jserv@linux2.cc.ntu.edu.tw)
Date: Wed Jul 21 00:13:06 2004
References: <20040720072054.GA2957@linux2.cc.ntu.edu.tw>
<200407201308.42374.ajax@nwnk.net>
Message-ID: <20040721072218.GA22296@linux2.cc.ntu.edu.tw>
On Tue, Jul 20, 2004 at 01:08:37PM -0400, Adam Jackson wrote:
> You just disabled three of the four transports X knows about. Since you=
=20
> probably don't have DECnet support in your kernel (no one does), the serv=
er=20
> will never be able to find a transport to listen on. Thus the "Cannot=20
> establish any listening sockets" error.
>=20
> You need to enable at least one of those, and you'll probably want both u=
nix=20
> and tcp.
Thanks for indicating me with th above points. I reconfigured again with
both tcp and unix transport enabled, but I still got the same errors.
It's strange that I configured xserver with the same configurations, and
it did work for me, but it does fail to work since I cvs update.
Is there any clue to solve this problem? Thanks!
Sincerely,
Jim Huang
From pocm at netvisao.pt Wed Jul 21 08:30:52 2004
From: pocm at netvisao.pt (Paulo Jorge O. C. Matos)
Date: Wed Jul 21 08:37:36 2004
Subject: [Xorg] Sudden change made me lose DRI
Message-ID: <87ekn5s7gz.fsf@netvisao.pt>
Hi all,
I had until recently kernel 2.4.x and xfree, now I changed to
xorg-6.7.0 and kernel 2.6.7, using gentoo linux.
I don't have for some reason dri enabled and I'm not being able
to make it work.
euler root # glxinfo | grep rendering
direct rendering: No
I load radeon and agpgart modules at startup. I have a ATI Radeon
Mobility 7500: (from lspci)
0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (r
ev 04)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc
Radeon Mobility M7 LW [Radeon Mobility 7500]
Well, I have the following in my xorg log:
...
(--) PCI:*(1:0:0) ATI Technologies Inc Radeon Mobility M7 LW
[Radeon Mobility 7500] rev 0, Mem @ 0xf0000000/27, 0xe8100000/16,
I/O @ 0x2000/8
...
...
(II) LoadModule: "radeon"
(II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o
(II) Module radeon: vendor="X.Org Foundation"
(II) LoadModule: "ati"
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="X.Org Foundation"
...
(--) Chipset ATI Radeon Mobility M7 LW (AGP) found
...
(II) Loading sub module "radeon"
(II) LoadModule: "radeon"
(II) Reloading /usr/X11R6/lib/modules/drivers/radeon_drv.o
...
(II) RADEON(0): MMIO registers at 0xe8100000
...
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) RADEON(0): PCI bus 1 card 0 func 0
(**) RADEON(0): Depth 16, (--) framebuffer bpp 16
(II) RADEON(0): Pixel depth = 16 bits stored in 2 bytes (16 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
(**) RADEON(0): Option "AGPMode" "4"
(**) RADEON(0): Option "AGPFastWrite" "true"
(**) RADEON(0): Option "EnablePageFlip" "true"
(==) RADEON(0): RGB weight 565
(II) RADEON(0): Using 6 bits per RGB (8 bit DAC)
...
(II) RADEON(0): initializing int10
(II) RADEON(0): Primary V_BIOS segment is: 0xc000
(--) RADEON(0): Chipset: "ATI Radeon Mobility M7 LW (AGP)" (ChipID = 0x4c57)
(--) RADEON(0): Linear framebuffer at 0xf0000000
(--) RADEON(0): VideoRAM: 32768 kByte (64 bit DDR SDRAM)
(II) RADEON(0): AGP card detected
...
(**) RADEON(0): Using AGP 4x mode
(**) RADEON(0): Enabling AGP Fast Write
(II) RADEON(0): Depth moves disabled by default
...
(II) RADEON(0): Page flipping enabled
(!!) RADEON(0): For information on using the multimedia capabilities
of this adapter, please see http://gatos.sf.net.
...
(WW) RADEON(0): Failed to set up write-combining range (0xf0000000,0x2000000)
drmOpenDevice: minor is 0
drmGetBusid returned ''
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0e5c000
(II) RADEON(0): [drm] mapped SAREA 0xe0e5c000 to 0x42265000
(II) RADEON(0): [drm] framebuffer handle = 0xf0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(WW) RADEON(0): [agp] AGP not available
(II) RADEON(0): [drm] removed 1 reserved context for kernel
(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0e5c000 at 0x42265000
(II) RADEON(0): Memory manager initialized to (0,0) (1408,8191)
(II) RADEON(0): Reserved area from (0,1050) to (1408,1052)
(II) RADEON(0): Largest offscreen area available: 1408 x 7139
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Scanline Image Writes
Offscreen Pixmaps
Setting up tile and stipple cache:
32 128x128 slots
32 256x256 slots
16 512x512 slots
(II) RADEON(0): Acceleration enabled
(==) RADEON(0): Backing store disabled
(==) RADEON(0): Silken mouse enabled
(II) RADEON(0): Using hardware cursor (scanline 1052)
(II) RADEON(0): Largest offscreen area available: 1408 x 7133
(II) RADEON(0): Direct rendering disabled
...
And in the end I have no direct rendering, does anybody know what
the problem might be?
Cheers,
--
Paulo J. Matos : pocm [_at_] mega . ist . utl . pt
Instituto Superior Tecnico - Lisbon
Computer and Software Eng. - A.I.
- > http://mega.ist.utl.pt/~pocm
---
-> God had a deadline...
So, he wrote it all in Lisp!
Date: Wed Jul 21 09:25:18 2004
In-Reply-To: <87ekn5s7gz.fsf@netvisao.pt>
References: <87ekn5s7gz.fsf@netvisao.pt>
Message-ID: <40FE9815.1060700@toya.net.pl>
Paulo Jorge O. C. Matos wrote:
> Hi all,
>
> I had until recently kernel 2.4.x and xfree, now I changed to
> xorg-6.7.0 and kernel 2.6.7, using gentoo linux.
> I don't have for some reason dri enabled and I'm not being able
> to make it work.
> euler root # glxinfo | grep rendering
> direct rendering: No
>
> I load radeon and agpgart modules at startup. I have a ATI Radeon
> Mobility 7500: (from lspci)
> 0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge
(rev 04)
> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc
> Radeon Mobility M7 LW [Radeon Mobility 7500]
Maybe try:
modprobe intel-agp
or
modprobe intel-mch-agp
--
Regards,
Jakub Piotr C?apa
Date: Wed Jul 21 09:26:26 2004
In-Reply-To: <87ekn5s7gz.fsf@netvisao.pt>
On Wed, 2004-07-21 at 16:30 +0100, Paulo Jorge O. C. Matos wrote:
>
> (WW) RADEON(0): [agp] AGP not available
Have you loaded the AGP kernel module for your chipset (before the
radeon DRM)? agpgart alone is no longer enough with 2.6 kernels.
--
From qbast at go2.pl Wed Jul 21 09:53:58 2004
Date: Wed Jul 21 10:12:37 2004
Subject: [Xorg] [PATCH] Security extension
Hello,
I've made a patch that allows to enable building Security extension
(-DXCSECURITY switch in Xorg) by passing --enable-xcsecurity switch to
configure. This extension is required for nvidia binary driver to work.
Patched debrix is available from my archive: qbast at go2.pl--2004
http://arch.hypair.net/archives as debrix--js--0.1--patch-5 .
I've also second branch (debrix--dynamic) that builds all modules as
external .so libs (no builtins). It works without problems (if you don't
count resolving dependencies between modules by hand) with binary nvidia
driver, scitech driver and other Xorg modules like cfb*, mfb and so on. You
only need to relink them (e.g. ld -shared nvidia_drv.o -o libnvidia.so). Main
advantage is that you don't need to add all those symbols to xf86sym.c (and
pray that next version of driver won't need another symbol).
-------------- next part --------------
Name: xsecurity.patch
Type: text/x-diff
Size: 5057 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040721/4d9422d9/xsecur
ity-0001.bin
From krahn at niehs.nih.gov Wed Jul 21 09:46:20 2004
Date: Wed Jul 21 10:41:20 2004
Subject: [Xorg] source of input
In-Reply-To: <Pine.SOL.4.44.0407200213410.28892-100000@rac3.wam.umd.edu>
References: <Pine.SOL.4.44.0407200213410.28892-100000@rac3.wam.umd.edu>
Message-ID: <40FE9DDC.6000809@niehs.nih.gov>
Matthew Evan Fowle wrote:
> i've been trying to write a multi-user window manager, sort of a x2x or
> synergy in reverse, but i cannot get off the ground: i am unable to find
> any means to detect which input source an input event was
> generated with.
You need to open the 2nd mouse as an extension device, and receive
extension events rather than pointer events. The 2nd mouse should also
be configured not to send core events (no AlwaysCore option).
>
> my goal is to be able to seperate the different input sources from one
> another. so i could have, for example, two mice, each with their own
> distinct cursor. i'm willing to implement a crude hack to share a
> CorePointer between two "fake" cursors (the "window manager"), but I have
> been unable to find any means to differentiate input between the two mice.
>
> if anyone has suggestions for how I can go about finding what physical
> device an input event (Motion, keyboard, or otherwise) was generated from,
> i would be very much oblidged.
There is now way to find what device an event came from, because the
XInput design never included support for more than one physical device
for one effective device. The "AlwaysCore" is just a hack.
Of course, with an extension device, it is up to you to draw a
cursor, manage the sub-windows, track window focus, and send
keyboard/pointer events to the appropriate sub-windows.
Joe Krahn
From tilo at pruetz.net Wed Jul 21 10:25:19 2004
From: tilo at pruetz.net (Tilo =?ISO-8859-1?Q?Pr=FCtz?=)
Date: Wed Jul 21 11:09:43 2004
Subject: ###Ist das Spam? Bitte einsortieren!### Re: [Xorg] Fail to run fd.o
Xserver
Message-ID: <1090430718.6920.17.camel@thor>
Hi,
I had the same problem with the xserver. Then I found a forum somewhere
(I don't remember where :)) where somebody said, that one should check
out the xtrans from the branch XTRANS-0_1-RELEASE instead of the trunk.
I did so and could start xserver successfully but because it hangs as
soon as I do more than an xterm, I changed back to xorg.
regards
>tilo
-------------- next part --------------
Name: not available
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://freedesktop.org/pipermail/xorg/attachments/20040721/7e36c23a/attach
ment.pgp
From ajax at nwnk.net Wed Jul 21 12:38:46 2004
Date: Wed Jul 21 12:08:42 2004
Subject: [Xorg] DRI fixes for libdl module loader
Hash: SHA1
I've got DRI and GLX working with the libdl module loader under current Xorg
CVS. It works well enough to run glxgears (both direct and indirect) and
quake3. The patch isn't quite finished, for two reasons. One, and rather
trivially, since the GLX code is shared with X11.app and Cygwin/X, their
indirect renderers need to be updated to match GLcore. This is effectively a
one-liner.
The second problem is trickier. GLX is in principle independent of DRI; you
can load it by itself and get just an indirect renderer in the server. The
reverse is not true, since atm DRI's functionality is implicitly tied to GL
contexts in the server. Clearly then, libglx has to load before libdri can
do anything useful.
There are two ways of expressing this. libglx could load libdri as a
submodule, the way it does libGLcore; or vice versa, libdri loads libglx.
With the first method, we'd need a way to suppress loading libdri (no
applicable hardware, or just the user doesn't want it). The 'omit' verb in
the config file syntax is probably sufficient. With the second method,
libdri becomes the top of the stack. I'm slightly in favor of the second
method, one because it doesn't change the behaviour of existing config files,
and two because it reinforces that DRI can be more than just a GL driver.
(Not that anyone has taken that route.)
One of my goals with the libdl loader work is ensuring that the user can load
any given module and it will work (if perhaps by doing nothing). Without one
of the two proposed changes above, configs that say Load "dri" before Load
"glx" will fail to start, and that's not acceptable.
The relevant bug is http://freedesktop.org/bugzilla/show_bug.cgi?id=377 .
I'll post patches there later tonight.
- - ajax
iD8DBQFA/sZJW4otUKDs0NMRAvx8AJwLPDQipTjCbVRI0Y4LbgmaZV4xJACg6j6R
C96527RIsn7ZXqfu7CxcDTs=
=65JH
From nemesis-lists at icequake.net Wed Jul 21 12:31:20 2004
From: nemesis-lists at icequake.net (Ryan Underwood)
Date: Wed Jul 21 12:56:49 2004
Subject: [Xorg] MGA patches
Message-ID: <20040721193120.GA14565@dbz.icequake.net>
Hi,
I have two patches in the XFree86 bug tracker which seem to be meeting
with disinterest on the "other side". I was wondering if anyone over
here had any comments or would like to merge them. I'm getting a little
tired of hand applying them to my systems.
http://bugs.xfree86.org/show_bug.cgi?id=1401
This is a simple patch which corrects the following misbehavior. If a
dualhead configuration is used in XF86Config, but dualhead is actually
disabled for some reason (usually due to an error during initialization
of the second head), then any video activity will immediately segfault
the server in MGASwapContextShared. Well, if dualhead isn't actually
being used, then there is no pointer to the second screen, so we should
use MGASwapContext instead.
This patch is more comprehensive, and adds support for the G-series
Maven chip. Through the Maven, it enables DDC and DPMS on the second
head of a G400 as well as TV cable detection. This is the first steps
towards removing the dependency on the mga HAL library; from here we
will have to figure out how to do mode setup through the Maven chip, but
the current features seem compelling enough to me to request it to be
included as-is.
I've been running both these patches on my system for at least a month
without any problems. However, I seem to have some problems getting
other people to test them.
Comments?
--
Ryan Underwood, <nemesis@icequake.net>
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040721/6ec6a053/attach
ment.pgp
From spook at spc.org Wed Jul 21 15:59:39 2004
From: spook at spc.org (spook)
Date: Wed Jul 21 15:59:43 2004
Subject: [Xorg] Memory usage under latest X.org server.
Message-ID: <20040721225939.GA44081@arginine>
Hello,

I have just installed slackware 10, which for the first time contains the

x.org xserver. It seems to work well for the most part, but my X process

uses far more memory than I could have imagined it would need, and causes my

system to act in a sluggish fashion. Previously, X would use a maximum of

20% of my 256M of ram, and my system would hardly ever use any swap. With

the new X.org server, my X process uses FAR more than this, and the longer

it stays running, the more it devours, including swap.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

27609 root 19 0 227m 173m 4380 R 5.3 69.3 23:32.92 X

(top output)

My gfx card is a Radeon 7000, PCI version. I have not specified a conf file

for X, but just run startx from the command line and go with the defaults. I

have asked on a number of forums but no one has been able to help, likewise

there is nothing that I could google that was pertinant. Any help that you

could shed on this would be much appreciated: I have no idea whether this is
a bug or a configuration bug.

Thanks

Date: Wed Jul 21 17:35:34 2004
Subject: [Xorg] New X.Org committers: DRI developers
I've added the DRI developers that weren't in x.org's list already to
the xorg group so that they'll be able to commit after the next merge
happens.
--
Date: Wed Jul 21 18:02:45 2004
Subject: [Xorg] Re: New X.Org committers: DRI developers
Message-ID: <a728f9f9040721180239592bf6@mail.gmail.com>
On Wed, 21 Jul 2004 17:31:28 -0700, Eric Anholt <eta@lclark.edu> wrote:
> I've added the DRI developers that weren't in x.org's list already to
> the xorg group so that they'll be able to commit after the next merge
> happens.
Cool. thanks Eric.
Alex
>
> --
>
Date: Wed Jul 21 18:08:13 2004
In-Reply-To: <1090425715.25045.28.camel@localhost> (Michel
=?iso-8859-1?q?D=E4nzer's?= message of "Wed,
21 Jul 2004 18:01:55 +0200")
References: <87ekn5s7gz.fsf@netvisao.pt> <1090425715.25045.28.camel@localhost>
Message-ID: <871xj4kg7q.fsf@mega.ist.utl.pt>
Michel D?nzer <michel@daenzer.net> writes:
> On Wed, 2004-07-21 at 16:30 +0100, Paulo Jorge O. C. Matos wrote:
>>
>> (WW) RADEON(0): [agp] AGP not available
>
> Have you loaded the AGP kernel module for your chipset (before the
> radeon DRM)? agpgart alone is no longer enough with 2.6 kernels.
>
>
Yes, I have the module loaded. I load agpgart and then radeon
module. However I get this from lsmod:
agpgart 26536 1 intel_agp
intel_agp 16796 1
radeon 122020 0
which means the radeon module is not being used:
Checking dmesg:
Linux agpgart interface v0.100 (c) Dave Jones
[drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI
Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]
agpgart: Detected an Intel i845 Chipset.
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 64M @ 0xec000000
radeonfb: cannot reserve FB region
[drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held
[drm:radeon_unlock] *ERROR* Process 10298 using kernel context 0
Any ideas on this issue?
Cheers,
Paulo Matos
> --
>
>
--
---
Date: Wed Jul 21 18:42:30 2004
Subject: [Xorg] cvs compile errors
Message-ID: <a728f9f9040721183540b2d2b9@mail.gmail.com>
FYI looks like freetype is broken in cvs:
gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef
-I/usr/include/freetype2 -I/usr/include/freetype2/config -I.
-I../../../include/fonts -I../include -I../../../exports/include/X11
-I../../../programs/Xserver/include
-I../../../exports/include -I../../..
-I../../../exports/include -Dlinux -D__i386__
-D_POSIX_C_SOURCE=199309L
-D_POSIX_SOURCE -D_XOPEN_SOURCE
-D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS
-DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
-DXFree86LOADER -DXFree86Server
-DXF86VIDMODE
-DXvMCExtension -DSMART_SCHEDULE
-DBUILDDEBUG -DXResExtension
-DX_BYTE_ORDER=X_LITTLE_ENDIAN
-DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7) * 100000) + ((0) *
1000) + 0)" -DXFREE86_FT2 -O2 -fno-strength-reduce
-fno-strict-aliasing ftfuncs.c -o unshared/ftfuncs.o
ftfuncs.c: In function `FT_Do_SBit_Metrics':
ftfuncs.c:931: error: structure has no member named `find_sbit_image'
ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
make[5]: *** [ftfuncs.o] Error 1
make[5]: Leaving directory `/home/alex/cvs/xorg/xc/lib/font/FreeType'
make[4]: *** [FreeType] Error 2
make[4]: Leaving directory `/home/alex/cvs/xorg/xc/lib/font'
make[3]: Leaving directory `/home/alex/cvs/xorg/xc/lib'
make[2]: Leaving directory `/home/alex/cvs/xorg/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/home/alex/cvs/xorg/xc'
make: *** [World] Error 2
Date: Wed Jul 21 18:52:59 2004
In-Reply-To: <871xj4kg7q.fsf@mega.ist.utl.pt>
<1090425715.25045.28.camel@localhost> <871xj4kg7q.fsf@mega.ist.utl.pt>
On Thu, 2004-07-22 at 02:01 +0100, Paulo Jorge O. C. Matos wrote:
> Michel D?nzer <michel@daenzer.net> writes:
>
> > On Wed, 2004-07-21 at 16:30 +0100, Paulo Jorge O. C. Matos wrote:
> >>
> >> (WW) RADEON(0): [agp] AGP not available
> >
> > Have you loaded the AGP kernel module for your chipset (before the
> > radeon DRM)? ^^^^^^^^^^
^^^^^^^^^^
> agpgart 26536 1 intel_agp
> intel_agp 16796 1
> radeon 122020 0
[...]
> Linux agpgart interface v0.100 (c) Dave Jones
> [drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI
> Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]
> agpgart: Detected an Intel i845 Chipset.
> agpgart: Maximum main memory to use for agp memory: 439M
> agpgart: AGP aperture is 64M @ 0xec000000
intel_agp seems to only get loaded after the DRM, so the DRM can't use
it.
--
Date: Wed Jul 21 18:59:23 2004
In-Reply-To: <a728f9f9040721183540b2d2b9@mail.gmail.com>
References: <a728f9f9040721183540b2d2b9@mail.gmail.com>
On Wed, 2004-07-21 at 18:35, Alex Deucher wrote:
> FYI looks like freetype is broken in cvs:
>
> gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef
> -I/usr/include/freetype2 -I/usr/include/freetype2/config -I.
> -I../../../include/fonts -I../include -I../../../exports/include/X11
> -I../../../programs/Xserver/include
> -I../../../exports/include -I../../..
> -I../../../exports/include -Dlinux -D__i386__
> -D_POSIX_C_SOURCE=199309L
> -D_POSIX_SOURCE -D_XOPEN_SOURCE
> -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS
> -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
> -DXFree86LOADER -DXFree86Server
> -DXF86VIDMODE
> -DXvMCExtension -DSMART_SCHEDULE
> -DBUILDDEBUG -DXResExtension
> -DX_BYTE_ORDER=X_LITTLE_ENDIAN
> -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7) * 100000) + ((0) *
> 1000) + 0)" -DXFREE86_FT2 -O2 -fno-strength-reduce
> -fno-strict-aliasing ftfuncs.c -o unshared/ftfuncs.o
> ftfuncs.c: In function `FT_Do_SBit_Metrics':
> ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
I've been seeing this issue on multiple systems as well, including the
FreeBSD tinderbox. I think the Linux build defaults to using system
Freetype, like FreeBSD does, and that this error might be something new
from freetype 2.1.8 usage. FreeBSD would have updated to freetype
2.1.9, but there are concerns about the rendering quality having
decreased since 2.1.7.
--
From seb.bel at sympatico.ca Wed Jul 21 19:33:18 2004
From: seb.bel at sympatico.ca (Seb)
Date: Wed Jul 21 19:36:15 2004
In-Reply-To: <20040721171241.285169F5C8@freedesktop.org>
References: <20040721171241.285169F5C8@freedesktop.org>
Message-ID: <40FF276E.4070804@sympatico.ca>
This is the same thing as what I emailed the list about.. the radeon
driver seems to not work with what ever changes were made to the DRI.
The net's full of people saying the same thing... Hense why a back port
of the changes would be appreciated... or at least a hint as to what we
could change in the code ourselves based on the changes... Seb >Message:
6 >Date: Wed, 21 Jul 2004 18:21:41 +0200 >From: Jakub Piotr C?apa
<loc@toya.net.pl> >Subject: Re: [Xorg] Sudden change made me lose DRI
>To: Xorg mailing list <xorg@freedesktop.org> >Message-ID:
<40FE9815.1060700@toya.net.pl> >Content-Type: text/plain; charset=UTF-8;
format=flowed >Paulo Jorge O. C. Matos wrote:
>> Hi all,
>>
>> I had until recently kernel 2.4.x and xfree, now I changed to
>> xorg-6.7.0 and kernel 2.6.7, using gentoo linux.
>> I don't have for some reason dri enabled and I'm not being able
>> to make it work.
>> euler root # glxinfo | grep rendering
>> direct rendering: No
>>
>> I load radeon and agpgart modules at startup. I have a ATI Radeon
>> Mobility 7500: (from lspci)
>> 0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge
(rev 04)
>> 0000:01:00.0 VGA compatible controller: ATI Technologies Inc
>> Radeon Mobility M7 LW [Radeon Mobility 7500]
>
>
>Maybe try:
>modprobe intel-agp
>or
>modprobe intel-mch-agp
Date: Wed Jul 21 19:59:09 2004
In-Reply-To: <1090461145.25045.39.camel@localhost> (Michel
=?iso-8859-1?q?D=E4nzer's?= message of "Thu,
22 Jul 2004 03:52:24 +0200")
References: <87ekn5s7gz.fsf@netvisao.pt> <1090425715.25045.28.camel@localhost>
<871xj4kg7q.fsf@mega.ist.utl.pt>
<1090461145.25045.39.camel@localhost>
Message-ID: <87r7r4vjbc.fsf@mega.ist.utl.pt>
You are correct. :) Many many thanks, it's working now. :)
Cheers,
Paulo Matos
Michel D?nzer <michel@daenzer.net> writes:
> On Thu, 2004-07-22 at 02:01 +0100, Paulo Jorge O. C. Matos wrote:
>> Michel D?nzer <michel@daenzer.net> writes:
>>
>> > On Wed, 2004-07-21 at 16:30 +0100, Paulo Jorge O. C. Matos wrote:
>> >>
>> >> (WW) RADEON(0): [agp] AGP not available
>> >
>> > Have you loaded the AGP kernel module for your chipset (before the
>> > radeon DRM)? ^^^^^^^^^^
> ^^^^^^^^^^
>
>> agpgart 26536 1 intel_agp
>> intel_agp 16796 1
>> radeon 122020 0
>
> [...]
>
>> Linux agpgart interface v0.100 (c) Dave Jones
>> [drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI
>> Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500]
>> agpgart: Detected an Intel i845 Chipset.
>> agpgart: Maximum main memory to use for agp memory: 439M
>> agpgart: AGP aperture is 64M @ 0xec000000
>
> intel_agp seems to only get loaded after the DRM, so the DRM can't use
> it.
>
>
> --
>
>
--
---
Date: Wed Jul 21 21:28:08 2004
<1090461257.894.110.camel@leguin>
Message-ID: <a728f9f904072121281b572177@mail.gmail.com>
> On Wed, 2004-07-21 at 18:35, Alex Deucher wrote:
> > FYI looks like freetype is broken in cvs:
> >
> > gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef
> > -I/usr/include/freetype2 -I/usr/include/freetype2/config -I.
> > -I../../../include/fonts -I../include -I../../../exports/include/X11
> > -I../../../programs/Xserver/include
> > -I../../../exports/include -I../../..
> > -I../../../exports/include -Dlinux -D__i386__
> > -D_POSIX_C_SOURCE=199309L
> > -D_POSIX_SOURCE -D_XOPEN_SOURCE
> > -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS
> > -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
> > -DXFree86LOADER -DXFree86Server
> > -DXF86VIDMODE
> > -DXvMCExtension -DSMART_SCHEDULE
> > -DBUILDDEBUG -DXResExtension
> > -DX_BYTE_ORDER=X_LITTLE_ENDIAN
> > -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7) * 100000) + ((0) *
> > 1000) + 0)" -DXFREE86_FT2 -O2 -fno-strength-reduce
> > -fno-strict-aliasing ftfuncs.c -o unshared/ftfuncs.o
> > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
>
> I've been seeing this issue on multiple systems as well, including the
> FreeBSD tinderbox. I think the Linux build defaults to using system
> Freetype, like FreeBSD does, and that this error might be something new
> from freetype 2.1.8 usage. FreeBSD would have updated to freetype
> 2.1.9, but there are concerns about the rendering quality having
> decreased since 2.1.7.
This was on a fedora core 2 system. building just the Xserver fails
as well on what looks like a related error:
gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
-pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o
../../programs/Xserver/hw/xfree86/common/xf86Init.o
../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
../../programs/Xserver/hw/xfree86/common/libxf86.a
../../programs/Xserver/hw/xfree86/parser/libxf86config.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
../../programs/Xserver/hw/xfree86/loader/libloader.a
../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a
os/libos.a ../../lib/font/fontbase.o
../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a
Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a
Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a randr/librandr.a
render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a
xkb/libxkb.a Xi/libxinput.a
lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
-lXau -lXdmcp -rdynamic -ldl
-Wl,-rpath-link,../../exports/lib
gcc: ../../lib/font/fontbase.o: No such file or directory
gcc: ../../lib/font/libfontbase.a: No such file or directory
make: *** [Xorg] Error 1
Any idea how I get around this?
Thanks,
Alex
> --
>
Date: Wed Jul 21 21:30:12 2004
In-Reply-To: <a728f9f904072121281b572177@mail.gmail.com>
<1090461257.894.110.camel@leguin>
<a728f9f904072121281b572177@mail.gmail.com>
On Thu, Jul 22, 2004 at 12:28:05AM -0400, Alex Deucher wrote:
> This was on a fedora core 2 system. building just the Xserver fails
> as well on what looks like a related error:
>
> gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> [...]
> gcc: ../../lib/font/fontbase.o: No such file or directory
> gcc: ../../lib/font/libfontbase.a: No such file or directory
> make: *** [Xorg] Error 1
>
> Any idea how I get around this?
That's really weird - libXfont isn't getting built. Do you have
BuildXfontLib set to NO anywhere? It's actually quite difficult to
bypass building this.
Aha, unless you build with make -k, in which libXfont failed to link,
but it kept stumbling on until it linked Xorg. It's probably the exact
same problem, and this is why I hate the monolithic tree, and -k.
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040722/af47fc7f/attach
ment.pgp
Date: Wed Jul 21 21:40:00 2004
<1090461257.894.110.camel@leguin>
On Wed, 2004-07-21 at 21:28, Alex Deucher wrote:
> On Wed, 21 Jul 2004 18:54:17 -0700, Eric Anholt <eta@lclark.edu> wrote:
> > On Wed, 2004-07-21 at 18:35, Alex Deucher wrote:
> > > FYI looks like freetype is broken in cvs:
> > >
> > > gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef
> > > -I/usr/include/freetype2 -I/usr/include/freetype2/config -I.
> > > -I../../../include/fonts -I../include -I../../../exports/include/X11
> > > -I../../../programs/Xserver/include
> > > -I../../../exports/include -I../../..
> > > -I../../../exports/include -Dlinux -D__i386__
> > > -D_POSIX_C_SOURCE=199309L
> > > -D_POSIX_SOURCE -D_XOPEN_SOURCE
> > > -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS
> > > -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
> > > -DXFree86LOADER -DXFree86Server
> > > -DXF86VIDMODE
> > > -DXvMCExtension -DSMART_SCHEDULE
> > > -DBUILDDEBUG -DXResExtension
> > > -DX_BYTE_ORDER=X_LITTLE_ENDIAN
> > > -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7) * 100000) + ((0) *
> > > 1000) + 0)" -DXFREE86_FT2 -O2 -fno-strength-reduce
> > > -fno-strict-aliasing ftfuncs.c -o unshared/ftfuncs.o
> > > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
> >
> > I've been seeing this issue on multiple systems as well, including the
> > FreeBSD tinderbox. I think the Linux build defaults to using system
> > Freetype, like FreeBSD does, and that this error might be something new
> > from freetype 2.1.8 usage. FreeBSD would have updated to freetype
> > 2.1.9, but there are concerns about the rendering quality having
> > decreased since 2.1.7.
>
>
> gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
> xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o
> ../../programs/Xserver/hw/xfree86/common/xf86Init.o
> ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
> ../../programs/Xserver/hw/xfree86/common/libxf86.a
> ../../programs/Xserver/hw/xfree86/parser/libxf86config.a
> ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
> ../../programs/Xserver/hw/xfree86/loader/libloader.a
> ../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a
> os/libos.a ../../lib/font/fontbase.o
> ../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a
> Xi/libxinput.a lbx/liblbx.a
> ../../lib/lbxutil/liblbxutil.a
> ../../programs/Xserver/hw/xfree86/common/libxf86.a
> Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.
a
> ../../lib/lbxutil/liblbxutil.a randr/librandr.a
> render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a
> xkb/libxkb.a Xi/libxinput.a
> lbx/liblbx.a
> ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
> ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
> -lXau -lXdmcp -rdynamic -ldl
> -Wl,-rpath-link,../../exports/lib
> gcc: ../../lib/font/fontbase.o: No such file or directory
> gcc: ../../lib/font/libfontbase.a: No such file or directory
> make: *** [Xorg] Error 1
>
> Any idea how I get around this?
If you haven't successfully built the font library (you failed in that
before with the previous error), you won't have the font-library-related
bits around to compile the server with.
I think setting #define HasFreetype2 NO in host.def would work around
this by building you a new freetype.
--
Date: Wed Jul 21 23:16:08 2004
In-Reply-To: <20040721193120.GA14565@dbz.icequake.net>
References: <20040721193120.GA14565@dbz.icequake.net>
On Wed, 2004-07-21 at 12:31, Ryan Underwood wrote:
> Hi,
>
> I have two patches in the XFree86 bug tracker which seem to be meeting
> with disinterest on the "other side". I was wondering if anyone over
> here had any comments or would like to merge them. I'm getting a little
> tired of hand applying them to my systems.
>
> http://bugs.xfree86.org/show_bug.cgi?id=1401
>
> This is a simple patch which corrects the following misbehavior. If a
> dualhead configuration is used in XF86Config, but dualhead is actually
> disabled for some reason (usually due to an error during initialization
> of the second head), then any video activity will immediately segfault
> the server in MGASwapContextShared. Well, if dualhead isn't actually
> being used, then there is no pointer to the second screen, so we should
> use MGASwapContext instead.
If this gets in our bugzilla, I'll commit it soon, if someone else
doesn't (the queue of patches in my tree is pretty large already).
>
> This patch is more comprehensive, and adds support for the G-series
> Maven chip. Through the Maven, it enables DDC and DPMS on the second
> head of a G400 as well as TV cable detection. This is the first steps
> towards removing the dependency on the mga HAL library; from here we
> will have to figure out how to do mode setup through the Maven chip, but
> the current features seem compelling enough to me to request it to be
> included as-is.
>
> I've been running both these patches on my system for at least a month
> without any problems. However, I seem to have some problems getting
> other people to test them.
This is pretty exciting. What concerns do you have about this code at
this point? Would any testing on a G400 singlehead help, and if so is
there any specific testing you would want done?
--
Date: Thu Jul 22 00:21:11 2004
Subject: [Xorg] X.Org DRI merge
OK, so current DRI sources have been merged. Sorry for the CVS logs not
being clear on the mailing list, but what happened was that after I
noticed that the Mesa log was huge I went and turned off logging until
after the conflict resolution. Probably should have turned it back on
before conflict resolution. On a related note, I feel like CVSROOT
modifications should also go to the mailing list, so people can know,
"OK, anholt's playing around with big imports and things will have
changed." Any opposition to doing so?
Now I'm doing final build testing and looking at hooking development
drivers up to the build in an appropriate way.
We'll also need someone to take a look at snapshots. One easy thing to
do (I hope) would be to just update the current snapshot scripts for the
new tree. The other possibility is to integrate snapshots into a DRI
tinderbox script, which I think would be pretty nice to have.
The advantage of the tinderbox route is that we get a pretty nifty way
to look at the logs when the build fails, and better knowledge of just
when the build began failing, should development become active enough
that nailing breakages down within the day is useful.
--
Date: Thu Jul 22 01:05:07 2004
Subject: [Xorg] Re: X.Org DRI merge
<1090482473.22799.7.camel@localhost>
On Thu, 2004-07-22 at 00:47, Donnie Berkholz wrote:
> On Thu, 2004-07-22 at 03:21, Eric Anholt wrote:
> > OK, so current DRI sources have been merged. Sorry for the CVS logs not
> > being clear on the mailing list, but what happened was that after I
> > noticed that the Mesa log was huge I went and turned off logging until
> > after the conflict resolution. Probably should have turned it back on
> > before conflict resolution. On a related note, I feel like CVSROOT
> > modifications should also go to the mailing list, so people can know,
> > "OK, anholt's playing around with big imports and things will have
> > changed." Any opposition to doing so?
>
> I'd rather also see huge logs. But that's just me.
I'm really mixed about that. It's somewhat nice for those of use with
nice connections, but I even now I'm not a fan of getting > 100K mails
for no reason. Most of that Mesa log is a bunch of uninformative "U"s.
However, that could be decreased significantly if I stopped doing
something bad in the Mesa import. Right now I just import a whole Mesa
tree, while the build doesn't need the progs, GLU, glut, etc. I should
figure out how to properly remove the existing files (cvs rm from the
vendor branch, I'm thinking), and add that list of files to remove to
the top of the Mesa tree so that it can be used in the importing
pseudo-script I've got. Doing that will be more of an improvement to
bandwidth/space usage than all the log avoidance we could ever do.
--
From spyderous at gentoo.org Thu Jul 22 00:47:53 2004
Date: Thu Jul 22 01:07:48 2004
On Thu, 2004-07-22 at 03:21, Eric Anholt wrote:
> OK, so current DRI sources have been merged. Sorry for the CVS logs not
> being clear on the mailing list, but what happened was that after I
> noticed that the Mesa log was huge I went and turned off logging until
> after the conflict resolution. Probably should have turned it back on
> before conflict resolution. On a related note, I feel like CVSROOT
> modifications should also go to the mailing list, so people can know,
> "OK, anholt's playing around with big imports and things will have
> changed." Any opposition to doing so?
I'd rather also see huge logs. But that's just me.
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040722/89833ee6/attach
ment.pgp
From keith at tungstengraphics.com Thu Jul 22 01:09:23 2004
Date: Thu Jul 22 01:29:00 2004
Subject: [Xorg] Re: DRI fixes for libdl module loader
References: <200407211538.54146.ajax@nwnk.net>
Message-ID: <40FF7633.3070907@tungstengraphics.com>
Adam Jackson wrote:
> Hash: SHA1
>
> I've got DRI and GLX working with the libdl module loader under current Xorg
> CVS. It works well enough to run glxgears (both direct and indirect) and
> quake3. The patch isn't quite finished, for two reasons. One, and rather
> trivially, since the GLX code is shared with X11.app and Cygwin/X, their
> indirect renderers need to be updated to match GLcore. This is effectively a
> one-liner.
>
> The second problem is trickier. GLX is in principle independent of DRI; you
> can load it by itself and get just an indirect renderer in the server. The
> reverse is not true, since atm DRI's functionality is implicitly tied to GL
> contexts in the server. Clearly then, libglx has to load before libdri can
> do anything useful.
>
> There are two ways of expressing this. libglx could load libdri as a
> submodule, the way it does libGLcore; or vice versa, libdri loads libglx.
> With the first method, we'd need a way to suppress loading libdri (no
> applicable hardware, or just the user doesn't want it). The 'omit' verb in
> the config file syntax is probably sufficient. With the second method,
> libdri becomes the top of the stack. I'm slightly in favor of the second
> method, one because it doesn't change the behaviour of existing config files,
> and two because it reinforces that DRI can be more than just a GL driver.
> (Not that anyone has taken that route.)
>
> One of my goals with the libdl loader work is ensuring that the user can load
> any given module and it will work (if perhaps by doing nothing). Without one
> of the two proposed changes above, configs that say Load "dri" before Load
> "glx" will fail to start, and that's not acceptable.
Can't this be expressed with the native library dependency mechanisms of the
OS? For instance, when you do 'ldd <somelibrary>', you get a list of other
libraries it depends upon. Why can't we use this native mechanism to express
the dependencies you're talking about?
Similarly, tasks like module init and module cleanup can be handled by native
mechanisms (if you're not already doing this), rather than by bolting on new
code around dlopen().
Keith
Date: Thu Jul 22 05:42:15 2004
In-Reply-To: <20040722043010.GE7042@fooishbar.org>
<1090461257.894.110.camel@leguin>
<20040722043010.GE7042@fooishbar.org>
Message-ID: <a728f9f9040722054263e3c606@mail.gmail.com>
On Thu, 22 Jul 2004 14:30:10 +1000, Daniel Stone <daniel@freedesktop.org> wrote:
> On Thu, Jul 22, 2004 at 12:28:05AM -0400, Alex Deucher wrote:
> > This was on a fedora core 2 system. building just the Xserver fails
> > as well on what looks like a related error:
> >
> > gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > [...]
> > gcc: ../../lib/font/fontbase.o: No such file or directory
> > gcc: ../../lib/font/libfontbase.a: No such file or directory
> > make: *** [Xorg] Error 1
> >
> > Any idea how I get around this?
>
> That's really weird - libXfont isn't getting built. Do you have
> BuildXfontLib set to NO anywhere? It's actually quite difficult to
> bypass building this.
Nope. I'm trying to start tracking xorg rather than DRI cvs and I
have a bunch of old patches I want to port to xorg, so I grabbed cvs
and tried "make world" that failed with the previous error, so I then
tried to build just the Xserver which resulted in this error.
>
> Aha, unless you build with make -k, in which libXfont failed to link,
> but it kept stumbling on until it linked Xorg. It's probably the exact
> same problem, and this is why I hate the monolithic tree, and -k.
it's all crazy magic to me ;)
>
> :) d
>
> --
> Daniel Stone <daniel@freedesktop.or
g>
> freedesktop.org: powering your desktop http://www.freedesktop.o
rg
>
>
>
Date: Thu Jul 22 05:50:17 2004
<1090476962.894.145.camel@leguin>
Message-ID: <a728f9f90407220550139743d5@mail.gmail.com>
> On Wed, 2004-07-21 at 12:31, Ryan Underwood wrote:
> > Hi,
> >
> > I have two patches in the XFree86 bug tracker which seem to be meeting
> > with disinterest on the "other side". I was wondering if anyone over
> > here had any comments or would like to merge them. I'm getting a little
> > tired of hand applying them to my systems.
> >
> > http://bugs.xfree86.org/show_bug.cgi?id=1401
> >
> > This is a simple patch which corrects the following misbehavior. If a
> > dualhead configuration is used in XF86Config, but dualhead is actually
> > disabled for some reason (usually due to an error during initialization
> > of the second head), then any video activity will immediately segfault
> > the server in MGASwapContextShared. Well, if dualhead isn't actually
> > being used, then there is no pointer to the second screen, so we should
> > use MGASwapContext instead.
>
> If this gets in our bugzilla, I'll commit it soon, if someone else
> doesn't (the queue of patches in my tree is pretty large already).
I can add this to my list as well, although I need to get my xorg tree
building first (stupid imake) ;-)
>
> > http://bugs.xfree86.org/show_bug.cgi?id=1098
> >
> > This patch is more comprehensive, and adds support for the G-series
> > Maven chip. Through the Maven, it enables DDC and DPMS on the second
> > head of a G400 as well as TV cable detection. This is the first steps
> > towards removing the dependency on the mga HAL library; from here we
> > will have to figure out how to do mode setup through the Maven chip, but
> > the current features seem compelling enough to me to request it to be
> > included as-is.
> >
> > I've been running both these patches on my system for at least a month
> > without any problems. However, I seem to have some problems getting
> > other people to test them.
>
> This is pretty exciting. What concerns do you have about this code at
> this point? Would any testing on a G400 singlehead help, and if so is
> there any specific testing you would want done?
when I get my xorg tree in shape I can try this on my G550. the only
thing is, I only have 1 monitor with a vga connector. my other one is
DVI only. What's odd is that when I use DVI only, the monitor works
fine. when I add the other monitor the server seems to go crazy.
perhaps you patch will help. One concern: do your general i2c
changes affect any other drivers? I don't want to break anything else
by accident.
Alex
>
> --
>
Date: Thu Jul 22 06:10:45 2004
<1090461257.894.110.camel@leguin>
<1090471196.894.133.camel@leguin>
Message-ID: <a728f9f90407220544d48b6d0@mail.gmail.com>
>
>
> On Wed, 2004-07-21 at 21:28, Alex Deucher wrote:
> > On Wed, 21 Jul 2004 18:54:17 -0700, Eric Anholt <eta@lclark.edu> wrote:
> > > On Wed, 2004-07-21 at 18:35, Alex Deucher wrote:
> > > > FYI looks like freetype is broken in cvs:
> > > >
> > > > gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef
> > > > -I/usr/include/freetype2 -I/usr/include/freetype2/config -I.
> > > > -I../../../include/fonts -I../include -I../../../exports/include/X11
> > > > -I../../../programs/Xserver/include
> > > > -I../../../exports/include -I../../..
> > > > -I../../../exports/include -Dlinux -D__i386__
> > > > -D_POSIX_C_SOURCE=199309L
> > > > -D_POSIX_SOURCE -D_XOPEN_SOURCE
> > > > -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
> > > > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS
> > > > -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
> > > > -DXFree86LOADER -DXFree86Server
> > > > -DXF86VIDMODE
> > > > -DXvMCExtension -DSMART_SCHEDULE
> > > > -DBUILDDEBUG -DXResExtension
> > > > -DX_BYTE_ORDER=X_LITTLE_ENDIAN
> > > > -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7) * 100000) + ((0) *
> > > > 1000) + 0)" -DXFREE86_FT2 -O2 -fno-strength-reduce
> > > > -fno-strict-aliasing ftfuncs.c -o unshared/ftfuncs.o
> > > > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > > > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > > > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
> > >
> > > I've been seeing this issue on multiple systems as well, including the
> > > FreeBSD tinderbox. I think the Linux build defaults to using system
> > > Freetype, like FreeBSD does, and that this error might be something new
> > > from freetype 2.1.8 usage. FreeBSD would have updated to freetype
> > > 2.1.9, but there are concerns about the rendering quality having
> > > decreased since 2.1.7.
> >
> > This was on a fedora core 2 system. building just the Xserver fails
> > as well on what looks like a related error:
> >
> > gcc -m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
> > xkb/xf86KillSrv.o xkb/xf86VT.o xkb/xf86Private.o
> > ../../programs/Xserver/hw/xfree86/common/xf86Init.o
> > ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
> > ../../programs/Xserver/hw/xfree86/common/libxf86.a
> > ../../programs/Xserver/hw/xfree86/parser/libxf86config.a
> > ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
> > ../../programs/Xserver/hw/xfree86/loader/libloader.a
> > ../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a
> > os/libos.a ../../lib/font/fontbase.o
> > ../../lib/font/libfontbase.a Xext/libexts.a xkb/libxkb.a
> > Xi/libxinput.a lbx/liblbx.a
> > ../../lib/lbxutil/liblbxutil.a
> > ../../programs/Xserver/hw/xfree86/common/libxf86.a
> > Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblb
x.a
> > ../../lib/lbxutil/liblbxutil.a randr/librandr.a
> > render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a
> > xkb/libxkb.a Xi/libxinput.a
> > lbx/liblbx.a
> > ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
> > ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
> > -lXau -lXdmcp -rdynamic -ldl
> > -Wl,-rpath-link,../../exports/lib
> > gcc: ../../lib/font/fontbase.o: No such file or directory
> > gcc: ../../lib/font/libfontbase.a: No such file or directory
> > make: *** [Xorg] Error 1
> >
> > Any idea how I get around this?
>
> If you haven't successfully built the font library (you failed in that
> before with the previous error), you won't have the font-library-related
> bits around to compile the server with.
>
> I think setting #define HasFreetype2 NO in host.def would work around
> this by building you a new freetype.
>
>
Thanks Eric. I'll give this a try tonight. Any idea how we can fix
this in the future so 'make World' just works?
Alex
>
> --
>
Date: Thu Jul 22 06:14:25 2004
In-Reply-To: Your message of "Thu, 22 Jul 2004 08:44:02 EDT."
<a728f9f90407220544d48b6d0@mail.gmail.com>
Message-ID: <E1BndOa-00042E-0Z@evo.keithp.com>
Around 8 o'clock on Jul 22, Alex Deucher wrote:
> > I think setting #define HasFreetype2 NO in host.def would work around
> > this by building you a new freetype.
>
> Thanks Eric. I'll give this a try tonight. Any idea how we can fix
> this in the future so 'make World' just works?
yes, fixing the font library to work with older versions of freetype
should be easy. That's the correct fix for this case; continuing to use a
private copy of freetype is a bad idea.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040722/bebc3b52/attach
ment.pgp
From lists at brachttal.net Thu Jul 22 07:22:03 2004
From: lists at brachttal.net (Andreas Volz)
Date: Thu Jul 22 07:59:16 2004
Subject: [Xorg] [x-server] Mouse Problem
Message-ID: <20040722162203.152bfb14.lists@brachttal.net>
Hi,
I could compile and install the x-server from CVS, but now if I start
the mouse doesn't work. I tried also to give -mouse /dev/input/mice as
parameter (it's an USB mouse), but it doesn't work. Which config file
does x-server use? Also /etc/X11/XF86config?
regards
Andreas
From torgeir at pobox.com Thu Jul 22 08:03:02 2004
Date: Thu Jul 22 08:03:09 2004
On Thu, 2004-07-15 at 10:13 -0700, Jon Smirl wrote:
> The talk is on Monday. Keith and others attending the conference will
> see everything you write here before then.
>
> Monday
> 3:30 - Video Drivers
> Session chair: Keith Packard
>
>
> There is also an X/Desktop developer conference happening at the same
> time. I suspect more detailed conversations will happen there.
> http://www.desktopcon.org/2004/
The only writeup I've seen yet is on lwn.net. Will someone post a
summary here?
--
Date: Thu Jul 22 10:29:26 2004
<1090461257.894.110.camel@leguin>
Message-ID: <ye83c3k7zbp.fsf@ec01.daimi.au.dk>
Alex Deucher <alexdeucher@gmail.com> writes:
I had the same problem, but I think it disappeared when I upgraded to
freetype 2.1.8. I haven't investigated further than that ...
S?ren
From ajax at nwnk.net Thu Jul 22 10:05:28 2004
Date: Thu Jul 22 11:19:16 2004
In-Reply-To: <40FF7633.3070907@tungstengraphics.com>
<40FF7633.3070907@tungstengraphics.com>
Hash: SHA1
On Thursday 22 July 2004 04:09, Keith Whitwell wrote:
> Can't this be expressed with the native library dependency mechanisms of
> the OS? For instance, when you do 'ldd <somelibrary>', you get a list of
> other libraries it depends upon. Why can't we use this native mechanism to
> express the dependencies you're talking about?
Yes it can, but I don't want to. Partly because it's tough to do that in some
cases without build-time hacks (though granted said build-time hack has
already been written [1]). Partly because the elfloader doesn't have this
ability and code-compatibility with both loaders is desirable. And partly
because if we let the runtime linker handle that, we may as well go whole hog
and do away with LoadSubModule() altogether.
I just don't feel that's the right approach yet. We've gotten on rather well
with having modules that know their needs at runtime, and the minimal
solution to make them work with the dlloader is to eliminate weak data
references, which is ~80 lines of diffs. This works iff the relationship
between modules is well-defined. The relationship between libglx and libdri
is not well-defined yet, but fixing that is a matter of another LoadSubModule
call in the right place. I'm just asking where people think the right place
is.
> Similarly, tasks like module init and module cleanup can be handled by
> native mechanisms (if you're not already doing this), rather than by
> bolting on new code around dlopen().
I'm not already doing this; people seem to want the elfloader to hang around
for a while.
- - ajax
[1] - http://freedesktop.org/bugzilla/attachment.cgi?id=176&action=view
iD8DBQFA//PYW4otUKDs0NMRAuKKAKDeCPguXUJ73zEN8FrTQCu925WMtgCcC4TN
x3zsFSzGXs4fdpHdbMtbBNk=
=PALY
Date: Thu Jul 22 12:33:52 2004
In-Reply-To: <40F6A9BF.7070807@us.ibm.com>
<ye87jt6k89n.fsf@horse04.daimi.au.dk>
<ye87jt5juqu.fsf@horse07.daimi.au.dk> <40F6A9BF.7070807@us.ibm.com>
Message-ID: <ye8k6wv7s6b.fsf@ec01.daimi.au.dk>
Ian Romanick <idr@us.ibm.com> writes:
> Soeren Sandmann wrote:
>
> > This essentially *changes* DefaultCCOptions for all of the framebuffer
> > code, which is not very nice. The problem is
> > (a) MMX intrinsics don't work with -pedantic
> > (b) DefaultCCOptions includes -pedantic
> > (c) There is no way to _remove_ options from DefaultCCOptions
> > Also, the code is written in a way that needs gcc's default inline
> > heuristics to be turned off, but that's not a problem because you can
> > easily *add* options to DefaultCCOptions.
> > If someone has a clean solution, please let me know. Personally I am
> > inclined to just remove -pedantic from
> > DefaultCCOptions, because the option it isn't really that useful.
>
> Would it maybe be better to add something like StrictCCWarningOptions
> that include -pedantic and is used only where it will work (i.e.,
> every place that doesn't use MMX intrinsics)? I've run into similar
> irritations before.
The problem is it will work a lot of places, so as far as I can see
you have to modify a lot of Imakefiles to do that.
But anyway I managed to get it compiling with -pedantic (with a ton of
warnings, though), so I have committed it. The build system related
changes are straight forward now (see below).
S?ren
Index: config/cf/xorg.cf
===================================================================
RCS file: /cvs/xorg/xc/config/cf/xorg.cf,v
diff -u -r1.11 xorg.cf
--- config/cf/xorg.cf 6 Jul 2004 23:50:59 -0000 1.11
+++ config/cf/xorg.cf 22 Jul 2004 18:03:42 -0000
@@ -1403,6 +1403,14 @@
# else
# define Gcc28Warnings /* */
# endif
+# ifndef HasGcc34
+# if (((GccMajorVersion == 3) && (GccMinorVersion >= 4)) || \
+ (GccMajorVersion > 3))
+# define HasGcc34 YES
+# else
+# define HasGcc34 NO
+# endif
+# endif
# endif
# ifndef GccWarningOptions
# if XFree86Devel
Index: programs/Xserver/fb/Imakefile
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/fb/Imakefile,v
diff -u -r1.3 Imakefile
--- programs/Xserver/fb/Imakefile 30 Jun 2004 20:06:53 -0000 1.3
+++ programs/Xserver/fb/Imakefile 22 Jul 2004 18:04:01 -0000
@@ -3,6 +3,11 @@
XCOMM
XCOMM Id: Imakefile,v 1.1 1999/11/02 03:54:44 keithp Exp $

+#if defined(i386Architecture) && defined(HasGcc34) && HasGcc34
+SpecialCObjectRule(fbmmx,fbmmx.c,-mmmx -Winline --param inline-unit-growth=1000
0 \
+ --param large-function-growth=10000 -DUSE_GCC34_MMX)
+#endif
+
#if DoLoadableServer
#if !BuildModuleInSubdir
#define IHaveModules
@@ -59,7 +64,8 @@
fbutil.c \
fbwindow.c \
fb24_32.c \
- fbpict.c
+ fbpict.c \
+ fbmmx.c

OBJS = $(XFMODOBJ) \
fbarc.o \
@@ -93,7 +99,8 @@
fbutil.o \
fbwindow.o \
fb24_32.o \
- fbpict.o
+ fbpict.o \
+ fbmmx.o

INCLUDES = -I$(SERVERSRC)/fb -I$(SERVERSRC)/mi -I$(SERVERSRC)/include \
-I$(XINCLUDESRC) \
@@ -161,6 +168,7 @@
LinkSourceFile(fbtrap.c,LinkDirectory)
LinkSourceFile(fbutil.c,LinkDirectory)
LinkSourceFile(fbwindow.c,LinkDirectory)
+LinkSourceFile(fbmmx.c,LinkDirectory)
#endif
InstallDriverSDKLibraryModule(fb,$(DRIVERSDKMODULEDIR),.)
From kamil.jiwa at gmail.com Thu Jul 22 10:56:46 2004
From: kamil.jiwa at gmail.com (Kamil Jiwa)
Date: Thu Jul 22 16:41:35 2004
Subject: [Xorg] Debrix Compile Problems
Message-ID: <e5f91a2e04072210569747d8d@mail.gmail.com>
I've checked out the latest Debrix tree (debrix--devel--0.1--patch-5)
and have been trying to compile it. I've installed the xlib packages
it requires and my configure runs smoothly. When I try to actually
compile it I run into a few problems.
Xext/sync.c:
In file included from ../sync.c:72:
../syncint.h:60: error: redefinition of `struct _SyncCounter'
../syncint.h:67: error: redefinition of `SyncCounter'
/usr/X11R6/include/X11/extensions/syncstr.h:379: error: `SyncCounter'
previously declared here
../syncint.h:74: error: conflicting types for `XSyncCounterNeverChanges'
/usr/X11R6/include/X11/extensions/syncstr.h:386: error: previous declaration of
`XSyncCounterNeverChanges'
and I continue to get several more errors of a similar nature. To fix
this, I commented out sync.c:72 #include "syncint.h" and it compiled
properly. I'm sure that this is not an acceptable solution, though.
Xext/shm.c:
As with sync.c, I get errors about redefinition of various types and
functions. As with sync.c, commenting out shm.c:63 #include "shmint.h"
allowed me to continue my build. And also, as with sync.c, I'm sure
that this is not an acceptable solution.
os/access.c:
In file included from access.c:193:
/usr/X11R6/include/X11/Xos_r.h:436: error: `MAXHOSTNAMELEN' undeclared
here (not in a function)
access.c: In function `LocalClient':
access.c:1340: warning: implicit declaration of function
`_XSERVTransGetPeerAddr'
access.c: In function `LocalClientCred':
access.c:1395: warning: implicit declaration of function `_XSERVTransIsLocal'
access.c:1399: warning: implicit declaration of function
`_XSERVTransGetConnectionNumber'
My build fails here and I'm not certain what I can do to fix it. I
have xlibs/xtrans installed. Need I install something else? It would
be nice to get these things cleared up so that I can get around to
making sure my automake files work alright before submitting them.
Some extra information:
gcc: 3.3.3 20040412
glibc: 2.3.3
... and I don't know what else might be relavent in this case. Thanks.
Kamil
From nemesis-lists at icequake.net Thu Jul 22 18:06:57 2004
Date: Thu Jul 22 18:07:10 2004
In-Reply-To: <a728f9f90407220550139743d5@mail.gmail.com>
<1090476962.894.145.camel@leguin>
<a728f9f90407220550139743d5@mail.gmail.com>
Message-ID: <20040723010657.GJ17121@dbz.icequake.net>
On Thu, Jul 22, 2004 at 08:50:15AM -0400, Alex Deucher wrote:
>
> I can add this to my list as well, although I need to get my xorg tree
> building first (stupid imake) ;-)
Yeah, I haven't built Xorg yet either. Actually, it was only recently
that I noticed that developers are hanging out here now instead of on
the XFree86 lists.
> > > This patch is more comprehensive, and adds support for the G-series
> > > Maven chip. Through the Maven, it enables DDC and DPMS on the second
> > > head of a G400 as well as TV cable detection. This is the first steps
> > > towards removing the dependency on the mga HAL library; from here we
> > > will have to figure out how to do mode setup through the Maven chip, but
> > > the current features seem compelling enough to me to request it to be
> > > included as-is.
> > >
> > > I've been running both these patches on my system for at least a month
> > > without any problems. However, I seem to have some problems getting
> > > other people to test them.
> >
> > This is pretty exciting. What concerns do you have about this code at
> > this point? Would any testing on a G400 singlehead help, and if so is
> > there any specific testing you would want done?
Unfortunately, this stuff is only for dualhead cards. However, if you
were to procure a dualhead upgrade (or a DVI upgrade) I would be
extremely interested in the results.
I haven't any concerns about the current code except that it doesn't
break people's systems which are already working fine with mga_hal.
Eventually I want to ease out of mga_hal being a requirement at all.
I'm tired of dealing with the occasional really strange problems that I
can only chalk up to its presence.
Now that we can talk to the maven chip/cell, we can do mode setup for
monitor, TV, or DVI. I have no idea how to detect a DVI port yet except
by using the PINS excrement that the BIOS leaves behind. In fact, I
need to update the code to handle the newest PINS revisions found in the
newer cards, because that's the only way we can determine the hardware
capabilities. (This stuff may not be externally detectable, only
flashed into the bios at the factory)
However, we can easily detect the TV cable and so do TV-based mode setup
when it is attached. That mode setup code is yet to be written because
I just moved and haven't gotten my AV rig set back up yet (but you can
see your cable detected or not detected in the server log, yay!)
I could work on the second head mode CRT mode setup right now.
Unfortunately, it's really hard to do driver hacking on the same box I
use for day to day work. I'd like to get another dualhead Matrox card
to put in my playground machine (which currently only has a single head
G400) but I can't afford it in the near future. If anyone has a G400
DH, G400Max or G450 laying around that is available for medium term
loan, let me know.

> when I get my xorg tree in shape I can try this on my G550. the only
> thing is, I only have 1 monitor with a vga connector. my other one is
> DVI only. What's odd is that when I use DVI only, the monitor works
> fine. when I add the other monitor the server seems to go crazy.
> perhaps you patch will help.
I think not. Like I said, no mode setup at the moment so we're still
stuck with mga_hal. The code can be written based on all the matroxfb
reverse engineering that Petr Vandrovec has already done (and has no
problems granting permission for X driver usage, if one felt the need to
flat out copy the code).
> One concern: do your general i2c
> changes affect any other drivers? I don't want to break anything else
> by accident.
The only change I recall is exposing a I2C function through the I2C
client structure. I had to write custom functions to access the
Maven because it seems to have some strange ideas regarding the I2C
protocol.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040722/cb5c9fb1/attach
ment.pgp
From saturn_vk at abv.bg Thu Jul 22 23:35:58 2004
From: saturn_vk at abv.bg (Viktor Kojouharov)
Date: Thu Jul 22 23:36:05 2004
Subject: [Xorg] xkb usage with multiple layouts
Message-ID: <719106428.1090564558913.JavaMail.nobody@app1.ni.bg>
is there any way to use these layouts together: us,bg,jp. some layouts, like us,
ru,au or other combinations can be used together, according to various sources.
however, upon trying to switch to us,bg,jp, I get an error:
saturn_vk@sat:~$ setxkbmap -layout us,bg,jp -variant ,phonetic, -v -v
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Warning! Multiple definitions of layout variant
Using command line, ignoring X server
Applied rules from base:
model: pc104
layout: us,bg,jp
variant: ,phonetic,
options: grp:ctrl_shift_toggle,grp_led:scroll
Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwerty)
types: complete
compat: complete+leds(scroll)
symbols: pc(pc104)+us+bg(phonetic):2+jp:3+group(ctrl_shift_toggle)
geometry: pc(pc104)
parse error: line 1 of pc
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Error interpreting include file "pc"
> Exiting
> Abandoning symbols file "default"
Errors from xkbcomp are not fatal to the X server
(EE) Error loading keymap /var/tmp/server-0.xkm
Error loading new keyboard description
I know for certain that these different keys can be used together. A cheap hack
is making one of the three inputs as a third level, however it's not pretty, and
it's not anywhere near perfect. Is there another way?
-----------------------------------------------------------------
http://www.elmaz.com/ - ????????????!
Date: Fri Jul 23 03:12:57 2004
Subject: [Xorg] XServer internals
Message-ID: <E1BnveS-0002cd-00@mailgate.rz.uni-karlsruhe.de>
I began to dive on X implementation. It lacks me a documentations of its.
The code is not well good documented and its very big to follow it. I have
already read ddx document from hardcopy/Xserver/ddx.PS.gz and it give me a
good start.
If you know others docs or internet site or books about Xserver internals,
please don't hesitate to tell me :-)
Amir Bukhari
E-Mail: ufz6@rz.uni-karlsruhe.de
Date: Fri Jul 23 06:00:59 2004
In-Reply-To: <Pine.LNX.4.58.0407231031130.5419@skynet>
<Pine.LNX.4.58.0407231031130.5419@skynet>
Message-ID: <a728f9f9040723060037fe806e@mail.gmail.com>
On Fri, 23 Jul 2004 10:32:55 +0100 (IST), Dave Airlie <airlied@linux.ie> wrote:
>
> also as far as I know the unichrome driver is in-secure it suffers I think
> the same issues as the savage and mach64 with its DDX setting up in-secure
> buffers...
>
> have a look at
> http://dri.sourceforge.net/IRC-logs/20040628.txt
>
> if this is so I recommend the via stuff goes in under devel for now ..
The 3d driver should definitly be, but as far as I recall, there is no
DRI enabled DDX component in the DRI tree. perhaps we should sync up
with the unichrome.sf.net tree? I thinks that's where most DDX, etc.
devel happens.
Alex
>
> Dave.
> --
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / airlied at skynet.ie
> pam_smb / Linux DECstation / Linux VAX / ILUG person
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
From andrew at digital-domain.net Thu Jul 22 10:24:16 2004
From: andrew at digital-domain.net (Andrew Clayton)
Date: Fri Jul 23 07:47:41 2004
Subject: [Xorg] Xinerama problem with a Matrox G450 and a Radeon 9200SE
Message-ID: <1090517055.2332.16.camel@alpha.digital-domain.net>
Hi,
I've been running an AGP Matrox G450 with two monitors in xinerama mode
for a couple of years.
In preparation to adding a third monitor to the xinerama mix, I added a
PCI Radeon 9200SE.
Before adding the third monitor I tried using xinerama across the two
cards (1 monitor connected to both cards). It's proving to be quite
tricky... but I think I'm close.
Eventually I would like to two end up with two monitors on the G450 and
one monitor on the 9200SE.
The current problem I'm having is that, when the G450 monitor is set as
screen 0 and the 9200SE monitor is set as Screen 1 in xorg.conf
(attached), the G450 one comes up but not the 9200SE and xinerama seems
to have been disabled. If I change the Screen 1 and 0 around in
xorg.conf, the 9200SE comes up but not the G450.
I've attached an xorg.conf and corresponding Xorg.0.log where the 9200SE
doesn't come up. It says that Screen 1 was deleted because there was no
config found, but I can't see whats missing.
As I said earlier, I've had the G450 running in xinerama ok. The 9200SE
does work in standalone mode. I can also run an X server on the G450 and
another X server on the 9200SE, just can't quite get them to work
together under xinerama.
This is under FC2.
Hopefully a fresh pair of eyes will see something....
Any help is much appreciated.
Cheers,
Andrew Clayton
-------------- next part --------------
# XFree86 4.0 configuration generated by Xconfigurator
Screen "Screen 1" RightOf "Screen 0"
EndSection
# By default, Red Hat Linux 6.0 and later use xfs
Section "Files"
FontPath "unix/:7100"
EndSection
# Module loading section
Section "Module"
Load "dbe" # Double-buffering
Load "GLcore" # OpenGL support
# Load "dri" # Direct rendering infrastructure
Load "glx" # OpenGL X protocol interface
Load "extmod" # Misc. required extensions
# Load "v4l" # Video4Linux
Load "record" # X event recorder
# You only need the following two modules if you do not use xfs.
Load "freetype" # TrueType font handler
Load "type1" # Adobe Type 1 font handler
EndSection
Option "Xinerama"
EndSection
Driver "keyboard"
Option "XkbLayout" "gb"
EndSection
Identifier "Mouse0"
Driver "mouse"
Option "Emulate3Buttons" "off"
EndSection
Section "Monitor"
Identifier "HM703U"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 30 - 96
VertRefresh 50 - 160
Option "dpms"
EndSection
Section "Monitor"
Identifier "Iiyama A701GT, VisionMasterPro 400"
VendorName "Unknown"
ModelName "Unknown"
HorizSync 27.0-96.0
VertRefresh 50.0-160.0
Option "dpms"
EndSection
Section "Device"
Identifier "G450"
Driver "mga"
BusID "PCI:1:0:0"
Option "AGPMode" "2"
Screen 0
EndSection
#Section "Device"
# Identifier "G450-1"
# Driver "mga"
# BusID "PCI:1:0:0"
# Option "AGPMode" "2"
# Screen 1
#EndSection
Section "Device"
Identifier "9200SE"
Driver "radeon"
Screen 1
EndSection
Section "Screen"
Identifier "Screen 0"
Device "G450"
Monitor "HM703U"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
Section "Screen"
Device "9200SE"
Monitor "Iiyama A701GT, VisionMasterPro 400"
DefaultDepth 16
Depth 16
Modes "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
#Section "DRI"
# Mode 0666
#EndSection
-------------- next part --------------
Name: Xorg.0.log
Type: text/x-log
Size: 29587 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040722/876264b2/Xorg.0
-0001.bin
Date: Fri Jul 23 08:00:08 2004
Subject: [Xorg] Xinerama problem with a Matrox G450 and a Radeon 9200SE
In-Reply-To: <1090517055.2332.16.camel@alpha.digital-domain.net>
References: <1090517055.2332.16.camel@alpha.digital-domain.net>
Message-ID: <a728f9f90407230800501e0f7d@mail.gmail.com>
On Thu, 22 Jul 2004 18:24:16 +0100, Andrew Clayton
<andrew@digital-domain.net> wrote:
> Hi,
>
> I've been running an AGP Matrox G450 with two monitors in xinerama mode
> for a couple of years.
>
> In preparation to adding a third monitor to the xinerama mix, I added a
> PCI Radeon 9200SE.
>
> Before adding the third monitor I tried using xinerama across the two
> cards (1 monitor connected to both cards). It's proving to be quite
> tricky... but I think I'm close.
>
> Eventually I would like to two end up with two monitors on the G450 and
> one monitor on the 9200SE.
>
> The current problem I'm having is that, when the G450 monitor is set as
> screen 0 and the 9200SE monitor is set as Screen 1 in xorg.conf
> (attached), the G450 one comes up but not the 9200SE and xinerama seems
> to have been disabled. If I change the Screen 1 and 0 around in
> xorg.conf, the 9200SE comes up but not the G450.
>
> I've attached an xorg.conf and corresponding Xorg.0.log where the 9200SE
> doesn't come up. It says that Screen 1 was deleted because there was no
> config found, but I can't see whats missing.
The "screen 0" and "screen 1" lines in your device sections are only
used for multi-head cards. what you want is something like this:
Section "Device"
Identifier "G450"
Driver "mga"
BusID "PCI:1:0:0"
EndSection
Section "Device"
Identifier "9200SE"
Driver "radeon"
EndSection
Screen 1 "Screen 1" RightOf "Screen 0"
EndSection
when you add the second g450 head into the mix add this:
Section "Device"
Identifier "G450-1"
Driver "mga"
BusID "PCI:1:0:0"
Screen 1
EndSection
As well as a third "screen" section, eg:
Section "Screen"
Device "G450-1"
Monitor "monitor3"
DefaultDepth 16
Subsection "Display"
Depth 16
Modes "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection
then update your layout, eg:
EndSection
Alex
>
> As I said earlier, I've had the G450 running in xinerama ok. The 9200SE
> does work in standalone mode. I can also run an X server on the G450 and
> another X server on the 9200SE, just can't quite get them to work
> together under xinerama.
>
> This is under FC2.
>
> Hopefully a fresh pair of eyes will see something....
>
> Any help is much appreciated.
>
> Cheers,
>
>
> Andrew Clayton
>
>
>
>
From vantr at touchtunes.com Fri Jul 23 07:45:06 2004
From: vantr at touchtunes.com (Tristan Van Berkom)
Date: Fri Jul 23 08:11:11 2004
In-Reply-To: <E1BnveS-0002cd-00@mailgate.rz.uni-karlsruhe.de>
References: <E1BnveS-0002cd-00@mailgate.rz.uni-karlsruhe.de>
Message-ID: <41012472.9070006@touchtunes.com>
Amir Bukhari wrote:
> I began to dive on X implementation. It lacks me a documentations of its.
> The code is not well good documented and its very big to follow it. I have
> already read ddx document from hardcopy/Xserver/ddx.PS.gz and it give me a
> good start.
> If you know others docs or internet site or books about Xserver internals,
> please don't hesitate to tell me :-)
I found this document very enlightening, I'm not sure if it ever
recieved any maintanence, but it should give you a good background ;-)
xc/programs/Xserver/hw/xfree86/doc/DESIGN
Cheers,
-Tristan
From qbast at go2.pl Fri Jul 23 08:40:13 2004
Date: Fri Jul 23 08:58:44 2004
<40FF7633.3070907@tungstengraphics.com>
<200407221305.29584.ajax@nwnk.net>
Dnia czw 22. lipca 2004 19:05, Adam Jackson napisa?:
> On Thursday 22 July 2004 04:09, Keith Whitwell wrote:
> > Can't this be expressed with the native library dependency mechanisms of
> > the OS? For instance, when you do 'ldd <somelibrary>', you get a list of
> > other libraries it depends upon. Why can't we use this native mechanism
> > to express the dependencies you're talking about?
>
> Yes it can, but I don't want to. Partly because it's tough to do that in
> some cases without build-time hacks (though granted said build-time hack
> has already been written [1]). Partly because the elfloader doesn't have
> this ability and code-compatibility with both loaders is desirable. And
> partly because if we let the runtime linker handle that, we may as well go
> whole hog and do away with LoadSubModule() altogether.
>
> I just don't feel that's the right approach yet. We've gotten on rather
> well with having modules that know their needs at runtime, and the minimal
> solution to make them work with the dlloader is to eliminate weak data
> references, which is ~80 lines of diffs. This works iff the relationship
> between modules is well-defined. The relationship between libglx and
> libdri is not well-defined yet, but fixing that is a matter of another
> LoadSubModule call in the right place. I'm just asking where people think
> the right place is.
>
> > Similarly, tasks like module init and module cleanup can be handled by
> > native mechanisms (if you're not already doing this), rather than by
> > bolting on new code around dlopen().
>
> I'm not already doing this; people seem to want the elfloader to hang
> around for a while.
>
I suggest doing more radical changes, like link-time dependencies, getting rid
of LoadSubModule() and init/cleanup functions in debrix (perhaps in separate
branch). As it is not mature yet and still needs some time and work, no one
would suffer from this - regular user would use 'stable' Xorg tree as usual
and developers would have time to get used to changes and see how it works in
reality.
> - ajax
>
> [1] - http://freedesktop.org/bugzilla/attachment.cgi?id=176&action=view
> _______________________________________________
> xorg mailing list
From Alan.Coopersmith at Sun.COM Fri Jul 23 09:47:01 2004
Date: Fri Jul 23 10:02:58 2004
In-Reply-To: <E1BnveS-0002cd-00@mailgate.rz.uni-karlsruhe.de>
Message-ID: <41014105.9060509@sun.com>
Amir Bukhari wrote:
> I began to dive on X implementation. It lacks me a documentations of its.
> The code is not well good documented and its very big to follow it. I have
> already read ddx document from hardcopy/Xserver/ddx.PS.gz and it give me a
> good start.
> If you know others docs or internet site or books about Xserver internals,
> please don't hesitate to tell me :-)
There is a long out-of-print book on Xserver Internals that used to be
published by Digital Press. While it was written for X11R5, many of the
basic concepts, especially the high level overview of how the code is
broken down into mi, dix, and ddx layers, is still relevant. Finding a
copy via used channels may be a bit of work, but it's still the best introductio
n
of it's kind I know of. (If only we could get Digital Press to open source
it so it could be updated to modern X servers...)
The X Window System Server: X Version 11, Release 5, Elias Israel and Erik Fortu
ne,
Digital Press - Digital Equipment Corporation, Bedford MA, 1992. ISBN 1-55558-09
6-3
--
Date: Fri Jul 23 10:22:57 2004
<200407221305.29584.ajax@nwnk.net>
<200407231740.14391.qbast@go2.pl>
Hash: SHA1
On Friday 23 July 2004 11:40, Jakub Stachowski wrote:
> I suggest doing more radical changes, like link-time dependencies, getting
> rid of LoadSubModule() and init/cleanup functions in debrix (perhaps in
> separate branch). As it is not mature yet and still needs some time and
> work, no one would suffer from this - regular user would use 'stable' Xorg
> tree as usual and developers would have time to get used to changes and see
> how it works in reality.
That's a good idea.
My original point is pretty much moot now, the most recent patch in #377 lets
you load any of the permutations (glx and dri in either order, glx only, dri
only, or neither) with reasonable behaviour - or at least the same behaviour
as the old loader. As it turns out, libdri without libglx will never touch
any of the glx-dependent code in libdri, because the app won't be able to
create a GL context.
- - ajax
iD8DBQFBAU+gW4otUKDs0NMRAkKrAJ9VwA161dF5JwSYPu3lFNvUFcS0BACdHrbW
TLstrrAS1fK4TfhlbgZi8jo=
=7gJ3
From Deron.Johnson at sun.com Fri Jul 23 15:21:21 2004
From: Deron.Johnson at sun.com (Deron Johnson)
Date: Fri Jul 23 15:24:10 2004
Subject: [Xorg] Re: xorg Digest, Vol 5, Issue 27
In-Reply-To: <E1Bj4wt-0006xS-Ne@pdx.freedesktop.org>
References: <E1Bj4wt-0006xS-Ne@pdx.freedesktop.org>
> DAMAGE/Composite:
> See my separate message about background == None windows, other
> than that, I've got several significant systems using Damage
> and Composite with good results, so I think we're in pretty
> good semantic shape here.
>
> We still haven't got a 'clean' Composite implementation running
> on XAA-based drivers (or in fact any drivers other than kdrive),
> Deron Johnson has implemented a more generic wrapper layer but
> hasn't sent that back to the community yet.
This generic wrapper layer is now available as a part of the lg3d-x11
project on java.net. I announced the lg3d-x11 project at the end of
June. This generic wrapper layer is called comptran and the code
for it is in Xserver/composite in the lg3d-x11 tree.
Stuart K. and I are currently working on merging this stuff into the
main Xorg tree. This will contain comptran plus other bug fixes I've
made to composite.
Keith: I'd like to set up a phone meeting to discuss the fixes I've
made to composite and lightpipe. Are you up for this? I can write up
and send out what I've done and then we can discuss it after you've
had a chance to review it.
As for the Project Looking Glass specific code, I'm not going to
be integrating that into the Xorg tree at this time. But I would like
to discuss whether/how to integrate this in the future. Basically,
there is a new extension LGE (Looking Glass Extension). This is fairly
modular. But what is not modular is that I've had to add (suitably
ifdef'd) code to various files such as events.c to support input
redirection to a 3D display server. I'm not sure whether people are
ready to accept this code at this point. What I've done my not be the
best way to do it in the long term.
Date: Fri Jul 23 16:01:02 2004
In-Reply-To: <41014105.9060509@sun.com>
<41014105.9060509@sun.com>
It is worth checking with the authors...
The contract we wrote for the base X Window System book
had the copyright revert to the authors if it went out of print
(ergo, I now own the copyright for the DP "added value" for
that volume (TOC, intro, index; the index has serious value)).
If Israel and Fortune has a similar contract, they may be
the owners.
If Israel and Fortune own the copyright, it may be easier than
pinging through Butterworth-Heinemann to find the right person
who could say yes. (Digital Press became part of B-H).
- Jim
On Fri, 2004-07-23 at 12:47, Alan Coopersmith wrote:
> (If only we could get Digital Press to open source
> it so it could be updated to modern X servers...)
>
> The X Window System Server: X Version 11, Release 5, Elias Israel and Erik For
tune,
> Digital Press - Digital Equipment Corporation, Bedford MA, 1992. ISBN 1-55558-
096-3
Date: Fri Jul 23 16:25:19 2004
In-Reply-To: Your message of "Fri, 23 Jul 2004 15:21:21 PDT."
<41018F61.2000709@Sun.COM>
Message-ID: <E1Bo9PZ-0002b7-Ta@evo.keithp.com>
Around 15 o'clock on Jul 23, Deron Johnson wrote:
> Keith: I'd like to set up a phone meeting to discuss the fixes I've
> made to composite and lightpipe. Are you up for this? I can write up
> and send out what I've done and then we can discuss it after you've
> had a chance to review it.
Let's focus on Composite only (lightpipe shouldn't affect the X.Org
release). Can you post a set of issues and ideas to this list and let's
see if we can't work out the problems here instead of attempting to
schedule a phone conference while I'm travelling.
> But what is not modular is that I've had to add (suitably
> ifdef'd) code to various files such as events.c to support input
> redirection to a 3D display server.
Right. It would be nice to make xevie capable of this, but that's not
pressing for the X.Org tree schedule.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040723/7026f7d6/attach
ment.pgp
From aplattner at nvidia.com Fri Jul 23 16:38:11 2004
From: aplattner at nvidia.com (Aaron Plattner)
Date: Fri Jul 23 16:42:40 2004
Subject: [Xorg] X.org driver support for RandR rotation
Message-ID: <20040723233811.GA2813@dhcp-177-188.nvidia.com>
Hello,
Currently, there is no way for a driver to be notified of RandR events. This
patch adds ScrnInfoRec functions which a driver can hook into to register which
rotations are supported and be notified when RandR events happen. This is
necessary mainly for hardware rotation support.
There are a few bugs that occur when the screen is rotated 90 or 270 degrees. A
few functions compare pScreen->{width,height} to mode sizes, which is incorrect
when the dimensions of the root window are swapped. This patch changes these
functions to use virtualX and virtualY, which are not swapped in rotated modes.
This bug also affects drivers such as nv and fbdev that support the "Rotate"
option in the config file. (To reproduce, use nv with 'Option "Rotate" "CW"'
and then try using Ctrl-Alt-+ and -).
-- Aaron Plattner
Index: hw/xfree86/common/xf86Cursor.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Cursor.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 xf86Cursor.c
--- hw/xfree86/common/xf86Cursor.c 25 Nov 2003 19:28:32 -0000 1.1.1.2
+++ hw/xfree86/common/xf86Cursor.c 23 Jul 2004 22:29:21 -0000
@@ -222,7 +222,7 @@
if (mode == pScr->currentMode)
return TRUE;

- if (mode->HDisplay > pScreen->width || mode->VDisplay > pScreen->height)
+ if (mode->HDisplay > pScr->virtualX || mode->VDisplay > pScr->virtualY)
return FALSE;

pCursorScreen = miPointerCurrentScreen();
Index: hw/xfree86/common/xf86Init.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Init.c,v
diff -u -r1.2 xf86Init.c
--- hw/xfree86/common/xf86Init.c 23 Apr 2004 19:20:32 -0000 1.2
+++ hw/xfree86/common/xf86Init.c 23 Jul 2004 22:29:21 -0000
@@ -897,6 +897,8 @@
xf86Screens[i]->DPMSSet = NULL;
xf86Screens[i]->LoadPalette = NULL;
xf86Screens[i]->SetOverscan = NULL;
+ xf86Screens[i]->RRGetInfo = NULL;
+ xf86Screens[i]->RRSetConfig = NULL;
scr_index = AddScreen(xf86Screens[i]->ScreenInit, argc, argv);
if (scr_index == i) {
/*
Index: hw/xfree86/common/xf86RandR.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86RandR.c,v
diff -u -r1.2 xf86RandR.c
--- hw/xfree86/common/xf86RandR.c 23 Apr 2004 19:20:32 -0000 1.2
+++ hw/xfree86/common/xf86RandR.c 23 Jul 2004 22:29:21 -0000
@@ -38,6 +38,7 @@
CloseScreenProcPtr CloseScreen;
int virtualX;
int virtualY;
+ Rotation rotation;
} XF86RandRInfoRec, *XF86RandRInfoPtr;

static int xf86RandRIndex;
@@ -77,8 +78,8 @@
return FALSE;
RRRegisterRate (pScreen, pSize, refresh);
if (mode == scrp->currentMode &&
- mode->HDisplay == pScreen->width && mode->VDisplay == pScreen->heigh
t)
- RRSetCurrentConfig (pScreen, RR_Rotate_0, refresh, pSize);
+ mode->HDisplay == scrp->virtualX && mode->VDisplay == scrp->virtualY
)
+ RRSetCurrentConfig (pScreen, randrp->rotation, refresh, pSize);
if (mode->next == scrp->modes)
break;
}
@@ -93,12 +94,17 @@
if (!pSize)
return FALSE;
RRRegisterRate (pScreen, pSize, refresh0);
- if (pScreen->width == randrp->virtualX &&
- pScreen->height == randrp->virtualY)
+ if (scrp->virtualX == randrp->virtualX &&
+ scrp->virtualY == randrp->virtualY)
{
- RRSetCurrentConfig (pScreen, RR_Rotate_0, refresh0, pSize);
+ RRSetCurrentConfig (pScreen, randrp->rotation, refresh0, pSize);
}
}
+
+ /* If there is driver support for randr, let it set our supported rotations
*/
+ if(scrp->RRGetInfo)
+ return (*scrp->RRGetInfo)(scrp, rotations);
+
return TRUE;
}

@@ -125,8 +131,17 @@
scrp->virtualX = mode->HDisplay;
scrp->virtualY = mode->VDisplay;
}
- pScreen->width = scrp->virtualX;
- pScreen->height = scrp->virtualY;
+ if(randrp->rotation & (RR_Rotate_90 | RR_Rotate_270))
+ {
+ /* If the screen is rotated 90 or 270 degrees, swap the sizes. */
+ pScreen->width = scrp->virtualY;
+ pScreen->height = scrp->virtualX;
+ }
+ else
+ {
+ pScreen->width = scrp->virtualX;
+ pScreen->height = scrp->virtualY;
+ }
if (!xf86SwitchMode (pScreen, mode))
{
scrp->virtualX = pScreen->width = oldWidth;
@@ -160,6 +175,8 @@
int px, py;
Bool useVirtual = FALSE;

+ randrp->rotation = rotation;
+
miPointerPosition (&px, &py);
for (mode = scrp->modes; ; mode = mode->next)
{
@@ -179,6 +196,12 @@
return FALSE;
}
}
+
+ /* Have the driver do its thing. */
+ if (scrp->RRSetConfig &&
+ !(*scrp->RRSetConfig)(scrp, rotation, rate, pSize->width, pSize->height
))
+ return FALSE;
+
if (!xf86RandRSetMode (pScreen, mode, useVirtual))
return FALSE;
/*
@@ -189,6 +212,7 @@
if (px < pSize->width && py < pSize->height)
(*pScreen->SetCursorPosition) (pScreen, px, py, FALSE);
}
+
return TRUE;
}

@@ -277,6 +301,8 @@
randrp->CloseScreen = pScreen->CloseScreen;
pScreen->CloseScreen = xf86RandRCloseScreen;

+ randrp->rotation = RR_Rotate_0;
+
pScreen->devPrivates[xf86RandRIndex].ptr = randrp;
return TRUE;
}
Index: hw/xfree86/common/xf86str.h
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86str.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 xf86str.h
--- hw/xfree86/common/xf86str.h 25 Nov 2003 19:28:33 -0000 1.1.1.2
+++ hw/xfree86/common/xf86str.h 23 Jul 2004 22:29:22 -0000
@@ -476,7 +476,7 @@
/* These values should be adjusted when new fields are added to ScrnInfoRec */
#define NUM_RESERVED_INTS 16
#define NUM_RESERVED_POINTERS 15
-#define NUM_RESERVED_FUNCS 12
+#define NUM_RESERVED_FUNCS 10

typedef pointer (*funcPointer)(void);

@@ -767,6 +767,8 @@
typedef void xf86DPMSSetProc (ScrnInfoPtr, int, int);
typedef void xf86LoadPaletteProc (ScrnInfoPtr, int, int *, LOCO *, VisualPtr)
;
typedef void xf86SetOverscanProc (ScrnInfoPtr, int);
+typedef Bool xf86RRGetInfoProc (ScrnInfoPtr, unsigned short *);
+typedef Bool xf86RRSetConfigProc (ScrnInfoPtr, int, int, int, int);

/*
* ScrnInfoRec
@@ -921,6 +923,8 @@
xf86DPMSSetProc *DPMSSet;
xf86LoadPaletteProc *LoadPalette;
xf86SetOverscanProc *SetOverscan;
+ xf86RRGetInfoProc *RRGetInfo;
+ xf86RRSetConfigProc *RRSetConfig;

/*
* This can be used when the minor ABI version is incremented.
From Deron.Johnson at Sun.COM Fri Jul 23 16:35:49 2004
From: Deron.Johnson at Sun.COM (Deron Johnson)
Date: Fri Jul 23 16:46:01 2004
In-Reply-To: <E1Bo9PZ-0002b7-Ta@evo.keithp.com>
References: <E1Bo9PZ-0002b7-Ta@evo.keithp.com>
Message-ID: <4101A0D5.4010109@Sun.COM>
Sure. I'll write something up and send it out.
> Around 15 o'clock on Jul 23, Deron Johnson wrote:
>
>
>>Keith: I'd like to set up a phone meeting to discuss the fixes I've
>>made to composite and lightpipe. Are you up for this? I can write up
>>and send out what I've done and then we can discuss it after you've
>>had a chance to review it.
>
>
> Let's focus on Composite only (lightpipe shouldn't affect the X.Org
> release). Can you post a set of issues and ideas to this list and let's
> see if we can't work out the problems here instead of attempting to
> schedule a phone conference while I'm travelling.
>
>
>>But what is not modular is that I've had to add (suitably
>>ifdef'd) code to various files such as events.c to support input
>>redirection to a 3D display server.
>
>
> Right. It would be nice to make xevie capable of this, but that's not
> pressing for the X.Org tree schedule.
>
> -keith
>
>
From svu at gnome.org Fri Jul 23 17:40:17 2004
From: svu at gnome.org (Sergey V. Udaltsov)
Date: Fri Jul 23 17:54:28 2004
Subject: [Xorg] ANNOUNCE: xkeyboard-config 0.3
Message-ID: <1090629617.7886.37.camel@sputnik>
After some delay, the third release of the project is out.
The main change in this release is HEAVY restructuring of the layouts
naming scheme - based on ISO standards (namely 639, 3166, 15924). Also,
the compatibility rules were added (not 100% complete though).
Some more documentation is put into the dosc subdirectory.
The i18n effort is under construction. The intltool is still causing
some warnings during the build process - but they are not critical and
can be ignored.
As usual, the feedback would be highly appreciated.
The sources can be downloaded from
http://freedesktop.org/~xlibs/release/xkeyboard-config-0.3.tar.gz
Regards,
Sergey
From Alan.Coopersmith at Sun.COM Fri Jul 23 18:44:42 2004
Date: Fri Jul 23 19:03:39 2004
In-Reply-To: <1090629617.7886.37.camel@sputnik>
References: <1090629617.7886.37.camel@sputnik>
Message-ID: <4101BF0A.5090204@Sun.COM>
Should these changes be incorporated into the upcoming August release
of Xorg? How far out of sync are we?
-alan-
Sergey V. Udaltsov wrote:
> After some delay, the third release of the project is out.
>
> The main change in this release is HEAVY restructuring of the layouts
> naming scheme - based on ISO standards (namely 639, 3166, 15924). Also,
> the compatibility rules were added (not 100% complete though).
>
> Some more documentation is put into the dosc subdirectory.
>
> The i18n effort is under construction. The intltool is still causing
> some warnings during the build process - but they are not critical and
> can be ignored.
>
> As usual, the feedback would be highly appreciated.
>
> The sources can be downloaded from
> http://freedesktop.org/~xlibs/release/xkeyboard-config-0.3.tar.gz
>
> Regards,
>
> Sergey
> _______________________________________________
> xorg mailing list
--
From svu at gnome.org Sat Jul 24 04:27:29 2004
Date: Sat Jul 24 04:25:45 2004
In-Reply-To: <4101BF0A.5090204@Sun.COM>
References: <1090629617.7886.37.camel@sputnik> <4101BF0A.5090204@Sun.COM>
Well, it is not for me to decide.
To the best of my knowledge, all layouts are in sync with the latest
stuff from xfree and xorg trees (well, I can be wrong at this point -
but not too much). A lot of layout-related bugs from fd.o bugzilla are
fixed (see the BUGS file in CVS).
Actually, I would really appreciate if someone could review the state of
the project and make some conclusion.
The only thing which bothers me is the state of translation. They were
not update for a long time. I could apply to the Translation Project
forces and hopefully get some new stuff.
Cheers,
Sergey
On Fri, 2004-07-23 at 18:44 -0700, Alan Coopersmith wrote:
> Should these changes be incorporated into the upcoming August release
> of Xorg? How far out of sync are we?
>
> -alan-
>
> Sergey V. Udaltsov wrote:
> > After some delay, the third release of the project is out.
> >
> > The main change in this release is HEAVY restructuring of the layouts
> > naming scheme - based on ISO standards (namely 639, 3166, 15924). Also,
> > the compatibility rules were added (not 100% complete though).
> >
> > Some more documentation is put into the dosc subdirectory.
> >
> > The i18n effort is under construction. The intltool is still causing
> > some warnings during the build process - but they are not critical and
> > can be ignored.
> >
> > As usual, the feedback would be highly appreciated.
> >
> > The sources can be downloaded from
> > http://freedesktop.org/~xlibs/release/xkeyboard-config-0.3.tar.gz
> >
> > Regards,
> >
> > Sergey
> > _______________________________________________
>
>
From matthieu.herrb at laas.fr Sat Jul 24 08:39:27 2004
Date: Sat Jul 24 08:55:26 2004
Subject: [Xorg] new comitter
Message-ID: <410282AF.3080707@laas.fr>
Hi,
I've been added as a comitter to xorg. I plan to work on OpenBSD (and
NetBSD) support and continue my work on general X security.
--
Matthieu Herrb
Date: Sat Jul 24 09:02:34 2004
<1090668449.7886.46.camel@sputnik>
On Sat, Jul 24, 2004 at 12:27:29PM +0100, Sergey V. Udaltsov wrote:
> To the best of my knowledge, all layouts are in sync with the latest
> stuff from xfree and xorg trees (well, I can be wrong at this point -
> but not too much). A lot of layout-related bugs from fd.o bugzilla are
> fixed (see the BUGS file in CVS).
>
> Actually, I would really appreciate if someone could review the state of
> the project and make some conclusion.
I've never been able to get it to build with intltool from Debian - it
complains about intltool stuff - having no intl/ directory and whatever.
I'd probably be able to give you better feedback if I'd ever been able
to build it. :)
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040725/b0f1333e/attach
ment.pgp
Date: Sat Jul 24 10:07:24 2004
<410282AF.3080707@laas.fr>
Message-ID: <E1BoPzG-0003z9-7k@evo.keithp.com>
Around 17 o'clock on Jul 24, Matthieu Herrb wrote:
> I've been added as a comitter to xorg. I plan to work on OpenBSD (and
> NetBSD) support and continue my work on general X security.
Cool. As you might know, we're planning a release near the end of August,
and it'd be nice to get better test coverage on those systems. We ran a
tinderbox for the last release on a few machines which helped catch build
issues. When we manage to get this running again, would you be able to
let us abuse machines to do automated build and Xvfb testing?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040724/5c4c1609/attach
ment.pgp
From reed at reedmedia.net Sat Jul 24 09:28:21 2004
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Sat Jul 24 10:08:16 2004
In-Reply-To: <410282AF.3080707@laas.fr>
Message-ID: <Pine.LNX.4.43.0407240917000.24109-100000@pilchuck.reedmedia.net>
On Sat, 24 Jul 2004, Matthieu Herrb wrote:
> I've been added as a comitter to xorg. I plan to work on OpenBSD (and
> NetBSD) support and continue my work on general X security.
Hello and welcome Matthieu,
Just to let you know, I am presently working on packaging XOrg 6.7.0 for
pkgsrc. I am first building under NetBSD. Then using same pkgsrc I'll make
sure it works for Linux too. I will be importing this xorg-tools and
xorg-libs packages to pkgsrc-wip first. http://pkgsrc-wip.sourceforge.net/
I helped create and help maintain the XFree86 packages for pkgsrc and
NetBSD too. For those who don't know: NetBSD maintains XFree86 in their
CVS which is the normal X11 installed with NetBSD, plus also provides it
as a third-party add-on via pkgsrc packages. The development of both is
unrelated. (In most cases, the packages aren't used by NetBSD users since
X11 is already installed; the pkgsrc maintained by NetBSD though is useful
on other operating systems, so the X can also be built and installed under
Linux and other BSDs for example using pkgsrc).
I also help package the xlibs components for pkgsrc, but temporarily gave
up do to needing a few libs which might be available now. Later, I plan to
try packaging debriX for pkgsrc (under NetBSD first) too.
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
Date: Sat Jul 24 10:57:30 2004
In-Reply-To: <20040724160231.GK4639@fooishbar.org>
<1090668449.7886.46.camel@sputnik>
<20040724160231.GK4639@fooishbar.org>
What was the last time you tried? In this release intltool is used in
somewhat "manual" mode (without standard configure.in macros) - so
probably you'll be able to build the stuff? If not - could you let me
know so I'll have a look.
Sergey
> I've never been able to get it to build with intltool from Debian - it
> complains about intltool stuff - having no intl/ directory and whatever.
> I'd probably be able to give you better feedback if I'd ever been able
> to build it. :)
Date: Sat Jul 24 11:09:27 2004
In-Reply-To: <20040724160231.GK4639@fooishbar.org>
<1090668449.7886.46.camel@sputnik>
<20040724160231.GK4639@fooishbar.org>
What was the last time you tried? In this release intltool is used in
somewhat "manual" mode (without standard configure.in macros) - so
probably you'll be able to build the stuff? If not - could you let me
know so I'll have a look.
Sergey
> I've never been able to get it to build with intltool from Debian - it
> complains about intltool stuff - having no intl/ directory and whatever.
> I'd probably be able to give you better feedback if I'd ever been able
> to build it. :)
Date: Sat Jul 24 19:02:50 2004
<1090668449.7886.46.camel@sputnik>
<20040724160231.GK4639@fooishbar.org>
<1090691709.7886.49.camel@sputnik>
On Sat, Jul 24, 2004 at 06:55:09PM +0100, Sergey V. Udaltsov wrote:
> What was the last time you tried? In this release intltool is used in
> somewhat "manual" mode (without standard configure.in macros) - so
> probably you'll be able to build the stuff? If not - could you let me
> know so I'll have a look.
I've been trying to build it for about a month now, on and off. Every
time, autogen.sh fails and I don't have the time to follow it through.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040725/17c983f5/attach
ment.pgp
From matthieu.herrb at laas.fr Sun Jul 25 07:32:34 2004
Date: Sun Jul 25 07:32:53 2004
Subject: [Xorg] build problem in dri in monolithic tree
Message-ID: <4103C482.7030402@laas.fr>
cc -c -O2 -ansi -Wall -Wpointer-arith -Wundef -fno-stack-protector
-I../../../../programs/Xserver/include -I../../../../exports/include
-I../../../../exports/include/X11
-I../../../../include/extensions -I../../../../extras/Mesa/include
-I../../../../programs/Xserver/hw/xfree86/os-support
-I../../../../programs/Xserver/hw/xfree86/common -I../include
-I../glx -I../../../../lib/GL/include
-I../../../../extras/drm/shared
-I../../../../programs/Xserver/mi -I../../../../include/fonts
-I../../../.. -I../../../../exports/include -DCSRG_BASED -DSHAPE
-DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT
-DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DXFIXES
-DDAMAGE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH
-DXFreeXDGA -DXvExtension -DXFree86Server -DXF86VIDMODE -DXvMCExtension
-DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000)
+ ((7) * 100000) + ((0) * 1000) + 0)" -DNDEBUG -DFUNCPROTO=15
-DNARROWPROTO -DXFree86Module -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING
-DGLX_USE_DLOPEN -DGLX_USE_MESA xf86dri.c
In file included from xf86dri.c:57:
dri.h:328: syntax error before `PciInfo'
*** Error code 1
(caused by the fact that dri.h references the pciVideoPtr type which is
defined in xf68str.h, but the latter header isn't included).
The attached patch fixes it, but since DRI is not my domain, I'm not
sure if it's the right fix.
Index: xf86dri.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/GL/dri/xf86dri.c,v
diff -u -r1.3 xf86dri.c
--- xf86dri.c 16 Jun 2004 09:37:58 -0000 1.3
+++ xf86dri.c 25 Jul 2004 14:29:58 -0000
@@ -53,6 +53,7 @@
#include "servermd.h"
#define _XF86DRI_SERVER_
#include "xf86dristr.h"
+#include "xf86str.h"
#include "swaprep.h"
#include "dri.h"
#include "sarea.h"
Index: dri.c
===================================================================
RCS file: /cvs/xorg/xc/programs/Xserver/GL/dri/dri.c,v
diff -u -r1.3 dri.c
--- dri.c 16 Jun 2004 09:37:58 -0000 1.3
+++ dri.c 25 Jul 2004 14:29:59 -0000
@@ -56,6 +56,7 @@
#include "servermd.h"
#define _XF86DRI_SERVER_
#include "xf86dristr.h"
+#include "xf86str.h"
#include "swaprep.h"
#include "dri.h"
#include "sarea.h"
--
Matthieu
From bryce at osdl.org Sun Jul 25 10:56:38 2004
From: bryce at osdl.org (Bryce Harrington)
Date: Sun Jul 25 11:01:53 2004
Message-ID: <Pine.LNX.4.33.0407250102190.9579-100000@osdlab.pdx.osdl.net>
Keithp writes:
> Around 17 o'clock on Jul 24, Matthieu Herrb wrote:
>> I've been added as a comitter to xorg. I plan to work on OpenBSD (and
>> NetBSD) support and continue my work on general X security.
>
> Cool. As you might know, we're planning a release near the end of
> August, and it'd be nice to get better test coverage on those systems.
> We ran a tinderbox for the last release on a few machines which helped
> catch build issues. When we manage to get this running again, would
> you be able to let us abuse machines to do automated build and Xvfb
> testing?
Hi Guys,
Jim approached me yesterday at the convention about tinderbox and other
testing that OSDL might be able to help with. (By the way, I loved all
the X talks - they were the most interesting part of the show!)
I know Cliff White was working on setting up Tinderbox for X here at
OSDL earlier. I'll check with him about it tomorrow - what is left to
be done on it?
As far as other testing, we've got some automated systems set up to run
regression and performance tests for the kernel and postgres. If
someone would like to work on this, we can expand the framework to
include running X tests. If this is something that X needs, I think
it'd be cool to get set up. :-)
(My OLS presentation slides on this are at:
http://developer.osdl.org/bryce/ols_testing_presentation/ )
Bryce
Date: Sun Jul 25 15:27:52 2004
In-Reply-To: <Pine.LNX.4.33.0407250102190.9579-100000@osdlab.pdx.osdl.net>
References: <Pine.LNX.4.33.0407250102190.9579-100000@osdlab.pdx.osdl.net>
On Sun, 2004-07-25 at 10:56, Bryce Harrington wrote:
> Keithp writes:
> > Around 17 o'clock on Jul 24, Matthieu Herrb wrote:
> >> I've been added as a comitter to xorg. I plan to work on OpenBSD (and
> >> NetBSD) support and continue my work on general X security.
> >
> > Cool. As you might know, we're planning a release near the end of
> > August, and it'd be nice to get better test coverage on those systems.
> > We ran a tinderbox for the last release on a few machines which helped
> > catch build issues. When we manage to get this running again, would
> > you be able to let us abuse machines to do automated build and Xvfb
> > testing?
>
> Hi Guys,
>
> Jim approached me yesterday at the convention about tinderbox and other
> testing that OSDL might be able to help with. (By the way, I loved all
> the X talks - they were the most interesting part of the show!)
>
> I know Cliff White was working on setting up Tinderbox for X here at
> OSDL earlier. I'll check with him about it tomorrow - what is left to
> be done on it?
>
> As far as other testing, we've got some automated systems set up to run
> regression and performance tests for the kernel and postgres. If
> someone would like to work on this, we can expand the framework to
> include running X tests. If this is something that X needs, I think
> it'd be cool to get set up. :-)
>
> (My OLS presentation slides on this are at:
> http://developer.osdl.org/bryce/ols_testing_presentation/ )
http://tinderbox.freedesktop.org
We've got a tinderbox build system already, though it's not in very good
shape. I feel like the script is a little fragile (after the DRI merge
I got some spurious errors for several runs, but now we're back to the
expected freetype errors). Mostly we're missing build machines. I've
set up a system doing normal and non-DRI builds on FreeBSD, but I don't
think I'll be able to keep that particular machine for very long. I've
got motherboards, CPUs, RAM, and disks here to set up some dedicated
tinderbox clients, but I need some ATX rackmount cases in order to house
them, and those are rather expensive :( So it looks like we need people
to run the scripts themselves unless I find a solution to the housing
issue.
There are several things that would be very nice to do with our
tinderbox. One would be to add a script option to tar up the results of
builds and make them available online, providing up-to-date binaries of
2d drivers and allowing us to phase out the DRI snapshot script we're
using currently. Another would be to collect a set of appropriate tests
(xtest suite, rendercheck?) to be run under Xvfb to test that DIX
remains sane. The tinderbox3 system has a lot of rough edges in terms
of general interface and configuration that could use polishing, too.
Hmm. If I had some of those machines working, and we were producing the
source tarballs periodically for snapshots, I could probably make some
xorg-snap ports for FreeBSD and set up a port build cluster locally to
catch breakages of 3rd-party apps. That could be really useful to do
before release.
--
Date: Sun Jul 25 16:33:56 2004
On Sun, 25 Jul 2004, Eric Anholt wrote:
> Mostly we're missing build machines. I've set up a system doing
> normal and non-DRI builds on FreeBSD, but I don't think I'll be able
> to keep that particular machine for very long. I've got motherboards,
> CPUs, RAM, and disks here to set up some dedicated tinderbox clients,
> but I need some ATX rackmount cases in order to house them, and those
> are rather expensive :( So it looks like we need people to run the
> scripts themselves unless I find a solution to the housing issue.
Do the scripts generate output that we could provide for inclusion in
this tinderbox? If so, we have some systems at OSDL that we could
probably run them on. If you can point me at the scripts, I'll look
into it.
> Another would be to collect a set of appropriate tests (xtest suite,
> rendercheck?) to be run under Xvfb to test that DIX remains sane.
Are these tests packaged separately or are they part of the X package?
Do the packages contain the docs for them?
> The tinderbox3 system has a lot of rough edges in terms
> of general interface and configuration that could use polishing, too.
For the kernel tinderbox (http://tinderbox.osdl.org/) we added a
legend.
Bryce
Date: Sun Jul 25 16:50:16 2004
> On Sun, 25 Jul 2004, Eric Anholt wrote:
> > Mostly we're missing build machines. I've set up a system doing
> > normal and non-DRI builds on FreeBSD, but I don't think I'll be able
> > to keep that particular machine for very long. I've got motherboards,
> > CPUs, RAM, and disks here to set up some dedicated tinderbox clients,
> > but I need some ATX rackmount cases in order to house them, and those
> > are rather expensive :( So it looks like we need people to run the
> > scripts themselves unless I find a solution to the housing issue.
>
> Do the scripts generate output that we could provide for inclusion in
> this tinderbox? If so, we have some systems at OSDL that we could
> probably run them on. If you can point me at the scripts, I'll look
> into it.
There are instructions at:
http://www.freedesktop.org/Software/TinderboxWiki
Thanks! Feedback is very welcome, too.
> > Another would be to collect a set of appropriate tests (xtest suite,
> > rendercheck?) to be run under Xvfb to test that DIX remains sane.
>
> Are these tests packaged separately or are they part of the X package?
> Do the packages contain the docs for them?
They aren't part of the monolithic build. I think xtest can be checked
out from the "xtest" module of xorg cvs instead of xc. I've never used
it myself, though. rendercheck is in xapps CVS
(:pserver:anoncvs@pdx.freedesktop:/cvs/xapps co rendercheck). It's
pretty new and lacks documentation, but it might be doable to check its
output using scripts anyway, though.
> > The tinderbox3 system has a lot of rough edges in terms
> > of general interface and configuration that could use polishing, too.
>
> For the kernel tinderbox (http://tinderbox.osdl.org/) we added a
> legend.
That legend does look much nicer than our interface. I was speaking
more to the administrator's interface, though, which I've been confused
by several times (sherriff/edit differentiation, broken logins,
mozilla-related defaults, I can't remember what else).
--
From alexdeucher at gmail.com Sun Jul 25 17:07:02 2004
Date: Sun Jul 25 17:07:08 2004
Subject: [Xorg] patch queue
Message-ID: <a728f9f904072517077c8755be@mail.gmail.com>
I've got a few patching I'm planning to commit in the next few days:
1. add Xv support to pre-nm2160 neomagic chipsets:
http://www.botchco.com/alex/xorg/neovideo.diff
This patch has been tested and works for Xv on the chipsets in
question. for more see:
2. radeon DynamicClocks (formerly DynamicPM) patch plus small fixups
and such from ati's last code drop (typo_fixes, remove_fudge, laptop,
xvfix)
dynamicclocks only:
http://www.botchco.com/alex/xorg/dynamicclocks.diff
dynamicclocks plus other small ati fixes:
http://www.botchco.com/alex/xorg/atiradeonfixes-plus-dynclocks.diff
The small fixes and clean ups from ati are pretty straight forward.
the DynamicClocks patch works fine for me (tested on m6, r100, rv280).
Some users report that is reduces the speed of certain openGL apps
when it's enabled. I haven't personally seen this. However it does
increase battery life on my laptop and also makes it run cooler (the
fan seems goes on less frequently). I have gotten quite a few other
reports of positive effects from using the patch. default is off.
more info:
http://www.sas.upenn.edu/~vbraun/computing/T41/power.html
3. Ryan's MGA patches.
the first one looks solid. the second? yes? no?
Thanks,
Alex
Date: Sun Jul 25 17:30:07 2004
> On Sun, 2004-07-25 at 16:33, Bryce Harrington wrote:
> > On Sun, 25 Jul 2004, Eric Anholt wrote:
> > > Mostly we're missing build machines.
> >
> > Do the scripts generate output that we could provide for inclusion in
> > this tinderbox? If so, we have some systems at OSDL that we could
> > probably run them on. If you can point me at the scripts, I'll look
> > into it.
>
> There are instructions at:
> http://www.freedesktop.org/Software/TinderboxWiki
>
> Thanks! Feedback is very welcome, too.
Ahh, interesting, yes this looks doable. What we have is an automated
system that manages a bunch of client machines, compiling/installing
stuff on them and running tests, wiping and re-installing between runs.
It sounds like doing a tinderbox run would be directly analogous to what
we're already doing.
However, is our environment "interesting" enough to be worth setting up
in this way? Basically, we've got ia32 systems with 1, 2, 4, and 8 cpu,
can install redhat 7.1 or 9.0 or suse 9.0, and pretty much any version
of the linux kernel (including all the major branches). Does this
environment sound like it would provide sufficient additional coverage?
Are there easy ways we could tweak it to provide more coverage (like
installing alternatives of particular libs/tools or other distros).
> > > Another would be to collect a set of appropriate tests (xtest suite,
> > > rendercheck?) to be run under Xvfb to test that DIX remains sane.
> >
> > Are these tests packaged separately or are they part of the X package?
> > Do the packages contain the docs for them?
>
> They aren't part of the monolithic build. I think xtest can be checked
> out from the "xtest" module of xorg cvs instead of xc. I've never used
> it myself, though. rendercheck is in xapps CVS
> (:pserver:anoncvs@pdx.freedesktop:/cvs/xapps co rendercheck). It's
> pretty new and lacks documentation, but it might be doable to check its
> output using scripts anyway, though.
Okay, thanks, I'll peek into these.
> > > The tinderbox3 system has a lot of rough edges in terms
> > > of general interface and configuration that could use polishing, too.
> >
> > For the kernel tinderbox (http://tinderbox.osdl.org/) we added a
> > legend.
>
> That legend does look much nicer than our interface. I was speaking
> more to the administrator's interface, though, which I've been confused
> by several times (sherriff/edit differentiation, broken logins,
> mozilla-related defaults, I can't remember what else).
I spoke with Cliff; looks like he's going to be gone for a good while
(caring for family). If there are urgent issues with Tinderbox to get
it ready for use in doing the August release, I can be available to
help. Otherwise I'll focus on seeing if we can scare up some more build
client resources.
Bryce
Date: Sun Jul 25 17:50:58 2004
> > On Sun, 2004-07-25 at 16:33, Bryce Harrington wrote:
> > > On Sun, 25 Jul 2004, Eric Anholt wrote:
> > > > Mostly we're missing build machines.
> > >
> > > Do the scripts generate output that we could provide for inclusion in
> > > this tinderbox? If so, we have some systems at OSDL that we could
> > > probably run them on. If you can point me at the scripts, I'll look
> > > into it.
> >
> > There are instructions at:
> > http://www.freedesktop.org/Software/TinderboxWiki
> >
> > Thanks! Feedback is very welcome, too.
>
> Ahh, interesting, yes this looks doable. What we have is an automated
> system that manages a bunch of client machines, compiling/installing
> stuff on them and running tests, wiping and re-installing between runs.
> It sounds like doing a tinderbox run would be directly analogous to what
> we're already doing.
>
> However, is our environment "interesting" enough to be worth setting up
> in this way? Basically, we've got ia32 systems with 1, 2, 4, and 8 cpu,
> can install redhat 7.1 or 9.0 or suse 9.0, and pretty much any version
> of the linux kernel (including all the major branches). Does this
> environment sound like it would provide sufficient additional coverage?
> Are there easy ways we could tweak it to provide more coverage (like
> installing alternatives of particular libs/tools or other distros).
We have no Linux tinderboxes running, so any Linux tinderbox would be
great. I would go with a recent redhat or suse. I'm thinking at this
point that I need to make some more tb server-controllable knobs in the
scripts. Adding a no-DRI control would be easy (I have it in the
scripts and I hand-edit the switch to "on" on the machine I do it on).
Checking different GCC versions might be useful, and adding a control
for that wouldn't be hard I don't think. If we get too many variables,
though, we'll have to figure out a better way of formatting the output.
> > > > The tinderbox3 system has a lot of rough edges in terms
> > > > of general interface and configuration that could use polishing, too.
> > >
> > > For the kernel tinderbox (http://tinderbox.osdl.org/) we added a
> > > legend.
> >
> > That legend does look much nicer than our interface. I was speaking
> > more to the administrator's interface, though, which I've been confused
> > by several times (sherriff/edit differentiation, broken logins,
> > mozilla-related defaults, I can't remember what else).
>
> I spoke with Cliff; looks like he's going to be gone for a good while
> (caring for family). If there are urgent issues with Tinderbox to get
> it ready for use in doing the August release, I can be available to
> help. Otherwise I'll focus on seeing if we can scare up some more build
> client resources.
I think build client resources are the biggest thing we need. Thanks!
--
Date: Sun Jul 25 17:53:39 2004
<1090803054.973.194.camel@leguin>
On Sun, Jul 25, 2004 at 05:50:54PM -0700, Eric Anholt wrote:
> On Sun, 2004-07-25 at 17:30, Bryce Harrington wrote:
> > However, is our environment "interesting" enough to be worth setting up
> > in this way? Basically, we've got ia32 systems with 1, 2, 4, and 8 cpu,
> > can install redhat 7.1 or 9.0 or suse 9.0, and pretty much any version
> > of the linux kernel (including all the major branches). Does this
> > environment sound like it would provide sufficient additional coverage?
> > Are there easy ways we could tweak it to provide more coverage (like
> > installing alternatives of particular libs/tools or other distros).
>
> We have no Linux tinderboxes running, so any Linux tinderbox would be
> great. I would go with a recent redhat or suse. I'm thinking at this
> point that I need to make some more tb server-controllable knobs in the
> scripts. Adding a no-DRI control would be easy (I have it in the
> scripts and I hand-edit the switch to "on" on the machine I do it on).
> Checking different GCC versions might be useful, and adding a control
> for that wouldn't be hard I don't think. If we get too many variables,
> though, we'll have to figure out a better way of formatting the output.
Run one on freedesktop.org, which is Debian, somewhere in between
testing and unstable. That's a Linux platform, and a very
widely-deployed one at that. :)
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/795eb1f4/attach
ment.pgp
Date: Sun Jul 25 18:09:51 2004
> great. I would go with a recent redhat or suse. I'm thinking at this
> point that I need to make some more tb server-controllable knobs in the
> scripts. Adding a no-DRI control would be easy (I have it in the
> scripts and I hand-edit the switch to "on" on the machine I do it on).
> Checking different GCC versions might be useful, and adding a control
> for that wouldn't be hard I don't think. If we get too many variables,
> though, we'll have to figure out a better way of formatting the output.
Okay, cool. The way our framework works is it allows selecting a test,
distro, machine, kernel (or other tools/libs) version, and additional
cmdline options to pass to the test wrapper. So any of those can be
varied as needed.
The one thing that's a bit odd is that since the machines are in a pool
and are used for a variety of other tests, we can't have them
continually running just one thing, so we could really only do runs
periodically (e.g., every 24 hrs or when a release is made.) So that
might be less useful than a dedicated machine; on the other hand, it
might be useful for providing a range of system configurations (such as
different versions of gcc or other tools/libs).
> I think build client resources are the biggest thing we need. Thanks!
Okay, cool.
By the way, at OSDL we also provide hardware access for open source
projects for specific testing projects. Typically these are intended
for use for a period of time (rather than indefinitely), but if people
need something like that, the hardware's there for use. There's a form
here:
http://www.osdl.org/lab_activities/lab_projects/propose_a_project.html
Some guidelines are here:
http://www.osdl.org/lab_activities/lab_projects
Bryce
Date: Sun Jul 25 18:17:49 2004
<1090803054.973.194.camel@leguin>
<20040726005337.GD3561@fooishbar.org>
<1090803794.973.197.camel@leguin>
Message-ID: <20040726011747.GF3561@fooishbar.org>
On Sun, Jul 25, 2004 at 06:03:15PM -0700, Eric Anholt wrote:
> On Sun, 2004-07-25 at 17:53, Daniel Stone wrote:
> > Run one on freedesktop.org, which is Debian, somewhere in between
> > testing and unstable. That's a Linux platform, and a very
> > widely-deployed one at that. :)
>
> I'm really bothered by the number of services we have running on that
> box, without any jailing at all. That's why I've been pushing to get
> the boxes elsewhere rather than just adding it to pdx. The tinderbox is
> also a lot of load -- 24/7 world-building, and maybe builds going in
> parallel.
I'll see what I can do about getting the services of another box. ITMT,
something like UML is a very interesting idea. I am personally not
immensely disturbed by the idea, but yes, we could do to have some
jailing. And separation of machines.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/efad7188/attach
ment-0001.pgp
From nemesis-lists at icequake.net Sun Jul 25 19:41:04 2004
Date: Sun Jul 25 19:41:08 2004
In-Reply-To: <a728f9f904072517077c8755be@mail.gmail.com>
References: <a728f9f904072517077c8755be@mail.gmail.com>
Message-ID: <20040726024104.GF12934@dbz.icequake.net>
On Sun, Jul 25, 2004 at 08:07:02PM -0400, Alex Deucher wrote:
> I've got a few patching I'm planning to commit in the next few days:
> ....
>
> 3. Ryan's MGA patches.
> the first one looks solid. the second? yes? no?
David Dawes committed the first one to XFree86 finally, FYI.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040725/79731bea/attach
ment.pgp
From alexander.gottwald at s1999.tu-chemnitz.de Sun Jul 25 23:57:52 2004
Date: Mon Jul 26 00:22:21 2004
<1090803054.973.194.camel@leguin>
> great. I would go with a recent redhat or suse.
I'd like to have cygwin in that list. Maybe not a dedicated machine but
a cross compile environment. But I don't have the machine or suitable
network access to host it myself.
bye
ago
--
From bjoernr at sensewave.com Mon Jul 26 03:03:34 2004
From: bjoernr at sensewave.com (bjoernr@sensewave.com)
Date: Mon Jul 26 03:22:53 2004
Subject: [Xorg] Building on Fedora Core 2 from the CVS-tree
Message-ID: <20040726100334.GB2545@gw.localdomain>
Hi!
I've a Fedora Core 2 system. The first attempt to build from CVS stoped because
of an error related to Freetype2. A search in email-lists, suggested that I mi
ght have a too old version of Freetype2 (allthough this is an updated version of
fc2). I excluded Freetype2 in my linux.cf file, and the compilation succeded.
Now I've trouble starting X with the "i810"-driver. It works with standard VGA
though.
Looks like the unresolved symbols depends on which modules are loaded (see below
).
I,m new too building xorg from CVS, soo this might bee a newbie question. Pleas
e bear with mee!
This is the error message printed to screen where I try to run "startx":
[bjoern@gw X11]$ startx
Build Operating System: Linux 2.6.6-1.435.2.3 i686 [ELF]
Current Operating System: Linux gw.localdomain 2.6.6-1.435.2.3 #1 Thu Jul 1 08:2
5:29 EDT 2004 i686
Symbol drmCommandNone from module /usr/X11R6/lib/modules/drivers/i810_drv.o is u
nresolved!
nresolved!
Fatal server error:
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional informati
on.
after 0 requests (0 known processed) with 0 events remaining.
Here are all the details from the log:
Build Operating System: Linux 2.6.6-1.435.2.3 i686 [ELF]
Current Operating System: Linux gw.localdomain 2.6.6-1.435.2.3 #1 Thu Jul 1 08:2
5:29 EDT 2004 i686
(==) ServerLayout "Simple Layout"
(**) |-->Screen "Screen 1" (0)
(**) | |-->Monitor "My Monitor"
(**) | |-->Device "** Intel i810 (generic) [i810]"
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) XKB: rules: "xorg"
(**) Option "XkbModel" "pc105"
(**) XKB: model: "pc105"
(**) Option "XkbLayout" "no"
(**) XKB: layout: "no"
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TT
F/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/
X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/local
/"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(II) Open APM successful
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="X.Org Foundation"
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="X.Org Foundation"
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x80000050, mode1Res1 = 0x80000000
(II) PCI: 00:1e:0: chip 8086,2418 card 0000,0000 rev 02 class 06,04,00 hdr 01
(II) PCI: 01:00:0: chip 1050,6692 card ffff,ffff rev ff class 02,80,00 hdr 00
(II) PCI: 01:02:0: chip 8086,1229 card 1014,005c rev 02 class 02,00,00 hdr 00
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-PCI bridge:
[0] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[1] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[2] -1 0 0x0000c800 - 0x0000c8ff (0x100) IX[B]
[3] -1 0 0x0000cc00 - 0x0000ccff (0x100) IX[B]
[0] -1 0 0xd4000000 - 0xd5ffffff (0x2000000) MX[B]
[0] -1 0 0xd6000000 - 0xd60fffff (0x100000) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:31:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(--) PCI:*(0:1:0) Intel Corp. 82810 CGC [Chipset Graphics Controller] rev 3, Mem
@ 0xd0000000/26, 0xd6100000/19
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
(II) Active PCI resource ranges:
[0] -1 0 0xd5000000 - 0xd50fffff (0x100000) MX[B]
[1] -1 0 0xd6001000 - 0xd6001fff (0x1000) MX[B]
[2] -1 0 0xd5100000 - 0xd5100fff (0x1000) MX[B]
[3] -1 0 0xd6000000 - 0xd6000fff (0x1000) MX[B]
[4] -1 0 0xd6100000 - 0xd617ffff (0x80000) MX[B](B)
[6] -1 0 0x0000c800 - 0x0000c81f (0x20) IX[B]
[7] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[8] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B]
[9] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
[10] -1 0 0x00005000 - 0x0000500f (0x10) IX[B]
[11] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[12] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
(II) Inactive PCI resource ranges:
[0] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
(II) Active PCI resource ranges after removing overlaps:
[0] -1 0 0xd5000000 - 0xd50fffff (0x100000) MX[B]
[1] -1 0 0xd6001000 - 0xd6001fff (0x1000) MX[B]
[2] -1 0 0xd5100000 - 0xd5100fff (0x1000) MX[B]
[3] -1 0 0xd6000000 - 0xd6000fff (0x1000) MX[B]
[4] -1 0 0xd6100000 - 0xd617ffff (0x80000) MX[B](B)
[6] -1 0 0x0000c800 - 0x0000c81f (0x20) IX[B]
[7] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[8] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B]
[9] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
[10] -1 0 0x00005000 - 0x0000500f (0x10) IX[B]
[11] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[12] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
(II) Inactive PCI resource ranges after removing overlaps:
[0] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xd5000000 - 0xd50fffff (0x100000) MX[B]
[6] -1 0 0xd6001000 - 0xd6001fff (0x1000) MX[B]
[7] -1 0 0xd5100000 - 0xd5100fff (0x1000) MX[B]
[8] -1 0 0xd6000000 - 0xd6000fff (0x1000) MX[B]
[9] -1 0 0xd6100000 - 0xd617ffff (0x80000) MX[B](B)
[11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[13] -1 0 0x0000c800 - 0x0000c81f (0x20) IX[B]
[14] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[15] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B]
[16] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
[17] -1 0 0x00005000 - 0x0000500f (0x10) IX[B]
[18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[19] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
[20] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
(II) LoadModule: "freetype"
(II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.a
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
(II) Loading font FreeType
(II) LoadModule: "i810"
(II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o
(II) Module i810: vendor="X.Org Foundation"
(II) Module mouse: vendor="X.Org Foundation"
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.4
(II) I810: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100,
i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G
(--) Assigning device section with no busID to primary device
(--) Chipset i810 found
(II) resource ranges after xf86ClaimFixedResources() call:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xd5000000 - 0xd50fffff (0x100000) MX[B]
[6] -1 0 0xd6001000 - 0xd6001fff (0x1000) MX[B]
[7] -1 0 0xd5100000 - 0xd5100fff (0x1000) MX[B]
[8] -1 0 0xd6000000 - 0xd6000fff (0x1000) MX[B]
[9] -1 0 0xd6100000 - 0xd617ffff (0x80000) MX[B](B)
[11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[13] -1 0 0x0000c800 - 0x0000c81f (0x20) IX[B]
[14] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[15] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B]
[16] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
[17] -1 0 0x00005000 - 0x0000500f (0x10) IX[B]
[18] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[19] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
[20] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
(II) resource ranges after probing:
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0xd5000000 - 0xd50fffff (0x100000) MX[B]
[6] -1 0 0xd6001000 - 0xd6001fff (0x1000) MX[B]
[7] -1 0 0xd5100000 - 0xd5100fff (0x1000) MX[B]
[8] -1 0 0xd6000000 - 0xd6000fff (0x1000) MX[B]
[9] -1 0 0xd6100000 - 0xd617ffff (0x80000) MX[B](B)
[11] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
[12] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
[13] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
[14] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[15] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[16] -1 0 0x0000c800 - 0x0000c81f (0x20) IX[B]
[17] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[18] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B]
[19] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
[20] -1 0 0x00005000 - 0x0000500f (0x10) IX[B]
[21] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[22] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
[23] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[24] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[25] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="X.Org Foundation"
(**) I810(0): Depth 8, (--) framebuffer bpp 8
(==) I810(0): Default visual is PseudoColor
(II) Module xaa: vendor="X.Org Foundation"
(**) I810(0): DRI is disabled because it runs only at 16-bit depth.
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Loading /usr/X11R6/lib/modules/libvbe.a
(II) Module vbe: vendor="X.Org Foundation"
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/X11R6/lib/modules/linux/libint10.a
(II) Module int10: vendor="X.Org Foundation"
(II) I810(0): initializing int10
(II) I810(0): Primary V_BIOS segment is: 0xc000
(II) I810(0): VESA BIOS detected
(II) I810(0): VESA VBE Version 3.0
(II) I810(0): VESA VBE Total Mem: 1024 kB
(II) I810(0): VESA VBE OEM: Intel(R) 8xx Chipset Video BIOS
(II) I810(0): VESA VBE OEM Software Rev: 4.0
(II) I810(0): VESA VBE OEM Vendor: Intel Corporation
(II) I810(0): VESA VBE OEM Product: Intel(R) 8xx Chipset
(II) I810(0): VESA VBE OEM Product Rev: Hardware Version 0.0
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="X.Org Foundation"
(II) I810(0): VESA VBE DDC supported
(II) I810(0): VESA VBE DDC Level 2
(II) I810(0): VESA VBE DDC transfer in appr. 1 sec.
(II) I810(0): VESA VBE DDC read successfully
(II) I810(0): Manufacturer: STN Model: c Serial#: 1347301689
(II) I810(0): Year: 2002 Week: 12
(II) I810(0): EDID Version: 1.3
(II) I810(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V
(II) I810(0): Sync: Separate
(II) I810(0): Max H-Image Size [cm]: horiz.: 36 vert.: 27
(II) I810(0): Gamma: 2.26
(II) I810(0): DPMS capabilities: StandBy Suspend Off; RGB/Color Display
(II) I810(0): First detailed timing is preferred mode
(II) I810(0): GTF timings supported
(II) I810(0): redX: 0.638 redY: 0.325 greenX: 0.276 greenY: 0.596
(II) I810(0): blueX: 0.143 blueY: 0.066 whiteX: 0.283 whiteY: 0.298
(II) I810(0): Supported VESA Video Modes:
(II) I810(0): 720x400@70Hz
(II) I810(0): 720x400@88Hz
(II) I810(0): 640x480@60Hz
(II) I810(0): 640x480@67Hz
(II) I810(0): 640x480@72Hz
(II) I810(0): 640x480@75Hz
(II) I810(0): 800x600@56Hz
(II) I810(0): 800x600@60Hz
(II) I810(0): 800x600@72Hz
(II) I810(0): 800x600@75Hz
(II) I810(0): 832x624@75Hz
(II) I810(0): 1024x768@87Hz (interlaced)
(II) I810(0): 1024x768@60Hz
(II) I810(0): 1024x768@70Hz
(II) I810(0): 1024x768@75Hz
(II) I810(0): 1280x1024@75Hz
(II) I810(0): 1152x870@75Hz
(II) I810(0): Manufacturer's mask: 0
(II) I810(0): Supported Future Video Modes:
(II) I810(0): #0: hsize: 640 vsize 480 refresh: 60 vid: 16433
(II) I810(0): Supported additional Video Mode:
(II) I810(0): clock: 157.5 MHz Image Size: 352 x 264 mm
(II) I810(0): h_active: 1280 h_sync: 1344 h_sync_end 1504 h_blank_end 1728 h_b
order: 0
(II) I810(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1072 v_b
order: 0
(II) I810(0): Ranges: V min: 50 V max: 160 Hz, H min: 30 H max: 96 kHz, PixClo
ck max 260 MHz
(II) I810(0): Monitor name: S/T 97P/96P
(II) I810(0): Serial No: HVAT305715
(--) I810(0): Chipset: "i810"
(--) I810(0): Linear framebuffer at 0xD0000000
(--) I810(0): IO registers at addr 0xD6100000
(II) I810(0): I810CheckAvailableMemory: 151548k available
(==) I810(0): Will alloc AGP framebuffer: 8192 kByte
(==) I810(0): Using gamma correction (1.0, 1.0, 1.0)
(II) I810(0): My Monitor: Using hsync range of 30.00-96.00 kHz
(II) I810(0): My Monitor: Using vrefresh range of 50.00-160.00 Hz
(II) I810(0): Clock range: 9.50 to 203.00 MHz
(II) I810(0): Not using default mode "320x175" (bad mode clock/interlace/doubles
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
(II) I810(0): Not using default mode "1024x768" (unknown reason)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
can)
(II) I810(0): Not using default mode "1600x1200" (bad mode clock/interlace/doubl
escan)
can)
escan)
can)
escan)
can)
escan)
can)
escan)
can)
escan)
can)
escan)
can)
can)
can)
can)
can)
can)
escan)
can)
escan)
(II) I810(0): Not using default mode "1024x768" (bad mode clock/interlace/double
scan)
escan)
scan)
escan)
scan)
(II) I810(0): Not using default mode "1600x1200" (width too large for virtual si
ze)
ze)
ze)
ze)
ze)
ze)
(--) I810(0): Virtual size is 1280x1024 (pitch 2048)
(II) I810(0): Modeline "1280x1024" 157.50 1280 1344 1504 1728 1024 1025 1028
1072 +hsync +vsync
(II) I810(0): Modeline "1024x768" 94.50 1024 1072 1168 1376 768 769 772 808
+hsync +vsync
(II) I810(0): Modeline "800x600" 56.30 800 832 896 1048 600 601 604 631 +hsy
nc +vsync
(II) I810(0): Modeline "640x480" 36.00 640 696 752 832 480 481 484 509 -hsyn
c -vsync
(II) I810(0): Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028
1066 +hsync +vsync
(II) I810(0): Modeline "1280x1024" 108.00 1280 1328 1440 1688 1024 1025 1028
1066 +hsync +vsync
(II) I810(0): Modeline "1280x960" 148.50 1280 1344 1504 1728 960 961 964 1011
+hsync +vsync
(II) I810(0): Modeline "1280x960" 108.00 1280 1376 1488 1800 960 961 964 1000
+hsync +vsync
(II) I810(0): Modeline "1152x864" 108.00 1152 1216 1344 1600 864 865 868 900
+hsync +vsync
(II) I810(0): Modeline "1152x768" 65.00 1152 1178 1314 1472 768 771 777 806
+hsync +vsync
(II) I810(0): Modeline "1024x768" 78.80 1024 1040 1136 1312 768 769 772 800
+hsync +vsync
(II) I810(0): Modeline "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806
-hsync -vsync
(II) I810(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806
-hsync -vsync
(II) I810(0): Modeline "832x624" 57.28 832 864 928 1152 624 625 628 667 -hsy
nc -vsync
nc +vsync
nc +vsync
nc +vsync
nc +vsync
c -vsync
c -vsync
c -vsync
c +vsync
c +vsync
(II) I810(0): Modeline "640x350" 31.50 640 672 736 832 350 382 385 445 +hsyn
c -vsync
(--) I810(0): Display dimensions: (360, 270) mm
(--) I810(0): DPI set to (90, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/X11R6/lib/modules/libfb.a
(II) Module fb: vendor="X.Org Foundation"
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Loading /usr/X11R6/lib/modules/libramdac.a
(II) Module ramdac: vendor="X.Org Foundation"
(II) I810(0): XvMC is Disabled: use XvMCSurfaces config option to enable.
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
[0] 0 0 0xd6100000 - 0xd617ffff (0x80000) MS[B]
[1] 0 0 0xd0000000 - 0xd3ffffff (0x4000000) MS[B]
[4] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[5] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[6] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[7] -1 0 0xd5000000 - 0xd50fffff (0x100000) MX[B]
[8] -1 0 0xd6001000 - 0xd6001fff (0x1000) MX[B]
[9] -1 0 0xd5100000 - 0xd5100fff (0x1000) MX[B]
[10] -1 0 0xd6000000 - 0xd6000fff (0x1000) MX[B]
[11] -1 0 0xd6100000 - 0xd617ffff (0x80000) MX[B](B)
[13] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
[14] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
[15] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
[16] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[17] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[18] -1 0 0x0000c800 - 0x0000c81f (0x20) IX[B]
[19] -1 0 0x0000c000 - 0x0000c0ff (0x100) IX[B]
[20] -1 0 0x0000dc00 - 0x0000dc3f (0x40) IX[B]
[21] -1 0 0x0000d800 - 0x0000d8ff (0x100) IX[B]
[22] -1 0 0x00005000 - 0x0000500f (0x10) IX[B]
[23] -1 0 0x0000d000 - 0x0000d01f (0x20) IX[B]
[24] -1 0 0x0000f000 - 0x0000f00f (0x10) IX[B]
[25] -1 0 0x0000c400 - 0x0000c4ff (0x100) IX[B]
[26] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
[27] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU)
(==) I810(0): Write-combining range (0xd0000000,0x4000000)
nresolved!
nresolved!
Fatal server error:
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional informati
on.
Best regards
Bjoern Rasmussen
From bjoernr at sensewave.com Mon Jul 26 02:59:50 2004
From: bjoernr at sensewave.com (bjoernr@sensewave.com)
Date: Mon Jul 26 03:38:32 2004
Subject: [Xorg] Uninstalling CVS-version of xorg
Message-ID: <20040726095950.GA2545@gw.localdomain>
Hi!
Sorry for this newbie question:
I've installed x.org from the CVS for the first time. Before I did that, I remo
ved all my xorg related rpms.
I've a Fedora Core 2 x86 system.
What's best practices for removing the CVS version again. I thought I could use
"make uninstall", but I cannot find any apropriate target in the Makefile in th
e root of the CVS-tree.
I'll apreciate any suggestions!
Best regards
Bjoern Rasmussen
Date: Mon Jul 26 07:27:55 2004
Bryce,
What we have going is a snapshot of tinderbox3 Cliff et. al. got
me back in April. We installed the tinderbox server on fd.o;
it was left pretty much alone. The server should just work when I
turn some of the existing clients back on (I turned several off
when I went off on vacation).
I (with John Dennis) hacked the client until we could build the CVS
based checkout/build of the X bits as the client only supported BK
properly at the time. As I was the one to finish up,
and am not a perl hacker, it is buggy (leaves you in the wrong directory
afterwards, so you end up recursively digging a deeper hole, filling
the tinderclient's machine with logs slowly).
At this point, we have (at least) 2 trees worth building. The
conventional CVS based tree built with Imake, and a modular tree
using autotools and jhbuild. jhbuild has some sort of tinderbox
feature, but I've not explored it.
As I'm not a perl hacker, I'm now lothe to spend more time on the
tinderbox scripts, as it isn't an efficient use of my time. There
are a number of people who might be able to help at our end.
As to platform coverage, the more the merrier.
We also have pretty wide test coverage possible for the older parts
of X in the test suite (which doesn't cover things like render, but
covers the older core parts of X pretty well).
Even just build testing on lots of platforms has shown itself to be very
useful.
- Jim
> > Mostly we're missing build machines. I've set up a system doing
> > normal and non-DRI builds on FreeBSD, but I don't think I'll be able
> > to keep that particular machine for very long. I've got motherboards,
> > CPUs, RAM, and disks here to set up some dedicated tinderbox clients,
> > but I need some ATX rackmount cases in order to house them, and those
> > are rather expensive :( So it looks like we need people to run the
> > scripts themselves unless I find a solution to the housing issue.
>
> Do the scripts generate output that we could provide for inclusion in
> this tinderbox? If so, we have some systems at OSDL that we could
> probably run them on. If you can point me at the scripts, I'll look
> into it.
>
> > Another would be to collect a set of appropriate tests (xtest suite,
> > rendercheck?) to be run under Xvfb to test that DIX remains sane.
>
> Are these tests packaged separately or are they part of the X package?
> Do the packages contain the docs for them?
>
> > The tinderbox3 system has a lot of rough edges in terms
> > of general interface and configuration that could use polishing, too.
>
> For the kernel tinderbox (http://tinderbox.osdl.org/) we added a
> legend.
>
> Bryce
>
> _______________________________________________
> xorg mailing list
Date: Mon Jul 26 07:51:15 2004
In-Reply-To: <1090852067.8895.23.camel@linux.site>
<1090852067.8895.23.camel@linux.site>
On Mon, 2004-07-26 at 07:27, Jim Gettys wrote:
> Bryce,
>
> What we have going is a snapshot of tinderbox3 Cliff et. al. got
> me back in April. We installed the tinderbox server on fd.o;
> it was left pretty much alone. The server should just work when I
> turn some of the existing clients back on (I turned several off
> when I went off on vacation).
I actually updated it last month when I was working on the tinderbox.
The source is in /usr/local/src/mozilla/webtools/tinderbox3, including
our local mods.
> I (with John Dennis) hacked the client until we could build the CVS
> based checkout/build of the X bits as the client only supported BK
> properly at the time. As I was the one to finish up,
> and am not a perl hacker, it is buggy (leaves you in the wrong directory
> afterwards, so you end up recursively digging a deeper hole, filling
> the tinderclient's machine with logs slowly).
Fixed that one.
--
Date: Mon Jul 26 07:53:27 2004
Subject: [Xorg] Re: Extension Extension
S?ren,
There are a number of other ways in which the current extension
framework is inadequate.
These include:
0) excessive round trips, causing poor startup time.
1) no way to reload an extension (to get new implementations).
2) no way to simultaneously run more than one version of an extension.
3) no way for extensions to come and go (think hotplug of screens,
coming at us; an extension may only apply to a given screen type,
for example).
There may be other issues that escape my mind.
Ok, where does this leave us?
a) some stuff can be done to mitigate the current round trip
problems; this can be done with or without an extension extension,
and, for downward compatibility's sake, in an ideal world we'd
do so on older X servers, by yet more internal Xlib batching
trickery (with or without using Xcb).
b) we need to decide whether to tackle all open issues with extensions,
or limit ourselves to those that can be solved even on older X servers
without an extension extension.
- Jim
From jens at tungstengraphics.com Mon Jul 26 08:10:08 2004
From: jens at tungstengraphics.com (Jens Owen)
Date: Mon Jul 26 08:40:13 2004
Subject: [Xorg] Re: Extension Extension
References: <1090853598.8895.34.camel@linux.site>
Message-ID: <41051ED0.6080705@tungstengraphics.com>
Jim Gettys wrote:
> 3) no way for extensions to come and go (think hotplug of screens,
> coming at us; an extension may only apply to a given screen type,
> for example).
at a more basic level, no way for an extension to exist on a per screen
basis. For the DRI, we had to determine if any of the screens supported
direct rendering; and if they did, we loaded the extension for the
server. Then an additional entry point was called to determine exactly
which screens really supported that feature.
--
/\
Jens Owen / \/\ _
jens@tungstengraphics.com / \ \ \ Steamboat Springs, Colorado
From carl at personnelware.com Mon Jul 26 08:44:46 2004
Date: Mon Jul 26 08:44:18 2004
Subject: [Xorg] tinderbox Q's
Message-ID: <003601c47327$7a7715c0$1e01a8c0@cnt496>
Where can I see the tinderbox statuses? (1 remote web page would be better than
me checking 3 or 4 local boxes.)
Is there any provision for a local cache? Like squid, rsync or anything so that
my set of boxes only has to hit the source once? Not that I care about my
bandwidth, but if a bunch of sites all have multiple boxes, it adds up.
Carl K
From matthieu.herrb at laas.fr Mon Jul 26 09:35:52 2004
Date: Mon Jul 26 09:35:58 2004
In-Reply-To: <003601c47327$7a7715c0$1e01a8c0@cnt496>
References: <003601c47327$7a7715c0$1e01a8c0@cnt496>
Message-ID: <410532E8.5010606@laas.fr>
Carl Karsten wrote:
> Where can I see the tinderbox statuses? (1 remote web page would be better th
an
> me checking 3 or 4 local boxes.)
>
> Is there any provision for a local cache? Like squid, rsync or anything so th
at
> my set of boxes only has to hit the source once? Not that I care about my
> bandwidth, but if a bunch of sites all have multiple boxes, it adds up.
Yes, it would be nice to be able to get a local copy of the xorg
repository through CVsup or cvsync (<http://www.cvsync.org/>).
I don't know if one of these are available on pdx.
--
Matthieu Herrb
-------------- next part --------------
Name: smime.p7s
Size: 4071 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/d26d7f9a/smime.
bin
Date: Mon Jul 26 09:44:11 2004
Subject: [Xorg] [PATCH] add 1280x854 mode to kdrive
I added a 1280x854 mode to kdrive on my flight back out to CA today and it
seems to work pretty well. I also added an ErrorF to the mode lookup
function so that finding missing modes is easier in the future. I'm not sure
about the t->rate stuff though, I didn't see an easy way to get that info
from fbdev.
Jesse
-------------- next part --------------
Name: kdrive-new-mode.patch
Type: text/x-diff
Size: 1737 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/335cac7f/kdrive
-new-mode.bin
Date: Mon Jul 26 09:52:27 2004
In-Reply-To: <410532E8.5010606@laas.fr>
References: <003601c47327$7a7715c0$1e01a8c0@cnt496> <410532E8.5010606@laas.fr>
On Mon, 2004-07-26 at 09:35, Matthieu Herrb wrote:
> Carl Karsten wrote:
> > Where can I see the tinderbox statuses? (1 remote web page would be better
than
> > me checking 3 or 4 local boxes.)
> >
> > Is there any provision for a local cache? Like squid, rsync or anything so
that
> > my set of boxes only has to hit the source once? Not that I care about my
> > bandwidth, but if a bunch of sites all have multiple boxes, it adds up.
>
> Yes, it would be nice to be able to get a local copy of the xorg
> repository through CVsup or cvsync (<http://www.cvsync.org/>).
>
> I don't know if one of these are available on pdx.
Yep, cvsup is set up. Here's my fd-supfile:
*default host=pdx.freedesktop.org
*default base=/usr/local/etc/cvsup/fdsup
*default prefix=/home/ncvs/freedesktop
*default release=cvs
*default delete use-rel-suffix
*default compress
xlibs
xserver
xapps
mesa
xorg
--
Date: Mon Jul 26 10:06:39 2004
<410532E8.5010606@laas.fr>
Message-ID: <E1Bp8vl-0001eA-CA@evo.keithp.com>
We run cvsup on freedesktop.org. Haven't looked at cvsync though.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/723e3dc5/attach
ment.pgp
Date: Mon Jul 26 10:09:36 2004
Subject: [Xorg] Re: [PATCH] add 1280x854 mode to kdrive
In-Reply-To: Your message of "Mon, 26 Jul 2004 11:44:39 EDT."
Message-ID: <E1Bp8yh-0001f5-1R@evo.keithp.com>
Ah, now all is clear. Thanks for the patch. Might be nice if fbdev could
use modes provided by the kernel which weren't listed in the X server...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/f18681d0/attach
ment.pgp
Date: Mon Jul 26 10:53:46 2004
Subject: [Xorg] Re: [PATCH] add 1280x854 mode to kdrive
In-Reply-To: <E1Bp8yh-0001f5-1R@evo.keithp.com>
References: <E1Bp8yh-0001f5-1R@evo.keithp.com>
On Monday, July 26, 2004 10:09 am, Keith Packard wrote:
> Ah, now all is clear. Thanks for the patch. Might be nice if fbdev could
> use modes provided by the kernel which weren't listed in the X server...
Yeah, that'll take me a little while longer since I'm not familiar with the
fbdev API. Btw, sorry if you got a few copies of the message, I was having
trouble with my mail daemon configuration (it mysteriously broke while I was
at OLS).
Jesse
Date: Mon Jul 26 11:30:27 2004
In-Reply-To: <410532E8.5010606@laas.fr>
Yes, this is important; I know Robin Cutshaw investigated reviving
his farm of systems, and this was the big issue he faced, and
I know that the commercial chip vendors also have this problem.
Have either of you ever set either of these servers up before?
- Jim
On Mon, 2004-07-26 at 12:35, Matthieu Herrb wrote:
> > Where can I see the tinderbox statuses? (1 remote web page would be better
than
> > me checking 3 or 4 local boxes.)
> >
> > Is there any provision for a local cache? Like squid, rsync or anything so
that
> > my set of boxes only has to hit the source once? Not that I care about my
> > bandwidth, but if a bunch of sites all have multiple boxes, it adds up.
>
>
> I don't know if one of these are available on pdx.
Date: Mon Jul 26 11:36:36 2004
<410532E8.5010606@laas.fr> <1090860442.886.5.camel@leguin>
The issue with CVSup is that it is a x86 only utility, due to
being one of the few applications written in Modula 3, for which there
is little or no ongoing maintenance.
Having something else available as well is probably a good long term
strategy...
- Jim

On Mon, 2004-07-26 at 12:47, Eric Anholt wrote:
> On Mon, 2004-07-26 at 09:35, Matthieu Herrb wrote:
> > Carl Karsten wrote:
> > > Where can I see the tinderbox statuses? (1 remote web page would be bette
r than
> > > me checking 3 or 4 local boxes.)
> > >
> > > Is there any provision for a local cache? Like squid, rsync or anything s
o that
> > > my set of boxes only has to hit the source once? Not that I care about my
> > > bandwidth, but if a bunch of sites all have multiple boxes, it adds up.
> >
> > Yes, it would be nice to be able to get a local copy of the xorg
> > repository through CVsup or cvsync (<http://www.cvsync.org/>).
> >
> > I don't know if one of these are available on pdx.
>
> Yep, cvsup is set up. Here's my fd-supfile:
>
> *default host=pdx.freedesktop.org
> *default base=/usr/local/etc/cvsup/fdsup
> *default prefix=/home/ncvs/freedesktop
> *default release=cvs
> *default delete use-rel-suffix
> *default compress
>
> xlibs
> xserver
> xapps
> mesa
> xorg
Date: Mon Jul 26 11:38:13 2004
<1090860442.886.5.camel@leguin>
<1090866990.9951.1.camel@linux.site>
On Mon, Jul 26, 2004 at 02:36:30PM -0400, Jim Gettys wrote:
> The issue with CVSup is that it is a x86 only utility, due to
> being one of the few applications written in Modula 3, for which there
> is little or no ongoing maintenance.
>
> Having something else available as well is probably a good long term
> strategy...
Personally, I just use rsync on /cvs/x{libs,server,apps,org}.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040727/adc159c0/attach
ment.pgp
From grifis87 at virgilio.it Mon Jul 26 13:50:39 2004
From: grifis87 at virgilio.it (Giovanni)
Date: Mon Jul 26 11:59:21 2004
Subject: [Xorg] suggestion for release.
Message-ID: <200407262050.39514.grifis87@virgilio.it>
I suggest to release a snapshot for alpha and beta..it would really be very
useful :)
thanks a lot
Giovanni
Date: Mon Jul 26 12:13:36 2004
<410532E8.5010606@laas.fr> <1090860442.886.5.camel@leguin>
<1090866990.9951.1.camel@linux.site>
On Mon, 2004-07-26 at 11:36, Jim Gettys wrote:
> The issue with CVSup is that it is a x86 only utility, due to
> being one of the few applications written in Modula 3, for which there
> is little or no ongoing maintenance.
>
> Having something else available as well is probably a good long term
> strategy...
Err, there's m3 for alpha, i386, and sparc64 at least, though I thought
it had been ported to more than that.
There's a "csup" (C CVSup) in the works to be imported into FreeBSD's
base system. I think mux is planning on releasing it pretty soon now.
--
From ajax at nwnk.net Mon Jul 26 12:27:38 2004
Date: Mon Jul 26 12:27:49 2004
In-Reply-To: <a728f9f904072517077c8755be@mail.gmail.com>
Hash: SHA1
On Sunday 25 July 2004 20:07, Alex Deucher wrote:
> I've got a few patching I'm planning to commit in the next few days:
>
> 1. add Xv support to pre-nm2160 neomagic chipsets:
> http://www.botchco.com/alex/xorg/neovideo.diff
> This patch has been tested and works for Xv on the chipsets in
> question. for more see:
Please close https://freedesktop.org/bugzilla/show_bug.cgi?id=321 once you do
commit this.
> 3. Ryan's MGA patches.
> the first one looks solid. the second? yes? no?
As long as the second one doesn't break people who are currently using the
HALlib, go for it.
- - ajax
iD8DBQFBBVsrW4otUKDs0NMRAgqyAKDQI6NhAW/CVpsBune5l4jbllYqrACaAstw
d2n4SeN/1IKXZo0tUoDl6WI=
=BGuy
From kem at freedesktop.org Mon Jul 26 12:59:49 2004
Date: Mon Jul 26 13:06:36 2004
In-Reply-To: <200407262050.39514.grifis87@virgilio.it>
References: <200407262050.39514.grifis87@virgilio.it>
On Mon, Jul 26, 2004 at 08:50:39PM +0000, Giovanni wrote:
> I suggest to release a snapshot for alpha and beta..it would really be very
> useful :)
I would like to make an alpha cut after the feature freeze on Friday,
and then a beta cut after the final freeze on 13 Aug 2004 for people to
test. Release candidates will follow the beta based on status of any
critical bug fixes.
From svetljo at gmx.de Mon Jul 26 13:14:31 2004
From: svetljo at gmx.de (Svetoslav Slavtchev)
Date: Mon Jul 26 13:21:14 2004
References: <20040726195949.GA21155@kem.org>
Message-ID: <30422.1090872871@www28.gmx.net>
> On Mon, Jul 26, 2004 at 08:50:39PM +0000, Giovanni wrote:
> > I suggest to release a snapshot for alpha and beta..it would really be
> very
> > useful :)
>
> I would like to make an alpha cut after the feature freeze on Friday,
> and then a beta cut after the final freeze on 13 Aug 2004 for people to
> test. Release candidates will follow the beta based on status of any
> critical bug fixes.
Hi,
do you have idea when are composite, damage & fixes going to be merged ?
i've some binary packages of almost current cvs for Mandrake devel,
and i was thinking to recompile them under Mandrake 10.0
when composite, damage and fixes got merged
best,
svetljo
--
NEU: WLAN-Router fr 0,- EUR* - auch fr DSL-Wechsler!
GMX DSL = supergnstig & kabellos http://www.gmx.net/de/go/dsl
From matthieu.herrb at laas.fr Mon Jul 26 14:27:29 2004
Date: Mon Jul 26 14:27:40 2004
Subject: [Xorg] a render patch
Message-ID: <41057741.70809@laas.fr>
Hi,
while reviewing the stuff I commited to OpenBSD's X tree since XFree86
4.4.0, I found this fix to render from Alan Houriane:
--- render.c 30 Jun 2004 20:06:56 -0000 1.3
+++ render.c 26 Jul 2004 21:20:09 -0000
@@ -1510,7 +1510,7 @@
}
pPicture = CreatePicture (0, &pPixmap->drawable, pFormat, 0, 0,
client, &error);
- if (!pPicture);
+ if (!pPicture)
{
xfree (argbbits);
xfree (srcbits);
This looks obviously correct to me, but a little review from Keith or
someone else who knows render internals better than me wouldn't hurt.
--
Matthieu
Date: Mon Jul 26 14:39:36 2004
Subject: [Xorg] a render patch
<41057741.70809@laas.fr>
Message-ID: <E1BpDBn-0001ze-5I@evo.keithp.com>
> while reviewing the stuff I commited to OpenBSD's X tree since XFree86
> 4.4.0, I found this fix to render from Alan Houriane:
That fix was already in the xserver repository as well. I recall getting
a bug report about this and fixing it; it causes cursors created with
pictures in non-ARGB32 format to fail.
Please feel free to commit the fix.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/c37988f6/attach
ment.pgp
From nemesis-lists at icequake.net Mon Jul 26 14:40:25 2004
Date: Mon Jul 26 14:40:29 2004
<200407261527.39993.ajax@nwnk.net>
Message-ID: <20040726214025.GA6936@dbz.icequake.net>
On Mon, Jul 26, 2004 at 03:27:38PM -0400, Adam Jackson wrote:
>
> > 3. Ryan's MGA patches.
> > the first one looks solid. the second? yes? no?
>
> As long as the second one doesn't break people who are currently using the
> HALlib, go for it.
I'm still using the HALlib too, unfortunately.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/945aed1b/attach
ment.pgp
From spyderous at gentoo.org Mon Jul 26 15:01:01 2004
Date: Mon Jul 26 15:12:33 2004
<1090860442.886.5.camel@leguin>
<1090866990.9951.1.camel@linux.site>
<1090869211.64841.51.camel@leguin>
Message-ID: <15580.205.241.48.33.1090879261.squirrel@spidermail.richmond.edu>
Eric Anholt said:
> On Mon, 2004-07-26 at 11:36, Jim Gettys wrote:
>> The issue with CVSup is that it is a x86 only utility, due to
>> being one of the few applications written in Modula 3, for which there
>> is little or no ongoing maintenance.
>>
>> Having something else available as well is probably a good long term
>> strategy...
>
> Err, there's m3 for alpha, i386, and sparc64 at least, though I thought
> it had been ported to more than that.
ppc also.
Donnie
Date: Mon Jul 26 18:28:54 2004
Subject: [Xorg] Xorg Tinderbox & firewalls
In-Reply-To: <003601c47327$7a7715c0$1e01a8c0@cnt496>
Message-ID: <4105AFD3.3080105@Sun.COM>
In order to get tinderbox running through our firewall (which requires
http proxy servers for http and socks proxies for cvs) I had to make
two simple changes to the tinderbox scripts.
The first I think is safe to go in the default since it simply checks
the environment for http_proxy settings:
--- /net/alf/export/alanc/X.org/tb/tinderclient/tinderclient.pl Mon Mar 8 12:10
:25 2004
+++ ./tinderclient.pl Sun Jul 25 22:13:41 2004
@@ -204,6 +204,7 @@
$this->{MACHINE_NAME} = $machine_name;
# The user agent object
$this->{UA} = new LWP::UserAgent;
+ $this->{UA}->env_proxy();
$this->{UA}->agent("TinderboxClient/" . $TinderClient::PROTOCOL_VERSION);
# the tinderclient.log out
$this->{LOG_OUT} = undef;
The second should probably be made configurable if it's added to the files
in CVS, otherwise just noted in the instructions for anyone who wants to do
this, since it adds "runsocks" to the CVS commands:
--- /net/alf/export/alanc/X.org/tb/tinderclient/TinderClientModules/XMonolithic.
pm Sat Jul 17 13:21:56 2004
+++ ./TinderClientModules/XMonolithic.pm Sun Jul 25 22:14:21 2004
@@ -45,11 +45,11 @@
$hostdef = $hostdef . "#define CcCmd ccache gcc\n";
$hostdef = $hostdef . "#define CplusplusCmd ccache g++\n";
}
# Build the cvs checkout cmd - note, the cvsroot variable must be set in t
he
# Tinderbox.
- $checkout_cmd = "cvs -z3 -d $cvsroot co -P ";
- $update_cmd = "cvs -z3 -d $cvsroot update -P ";
+ $checkout_cmd = "runsocks cvs -z3 -d $cvsroot co -P ";
+ $update_cmd = "runsocks cvs -z3 -d $cvsroot update -P ";
if ($branch) {
$checkout_cmd .= "-r$branch ";
--
Date: Mon Jul 26 20:00:35 2004
Subject: [Xorg] [PATCH] add 1280x854 mode to kdrive
I added a 1280x854 mode to kdrive on my flight back out to CA today and it
seems to work pretty well. I also added an ErrorF to the mode lookup
function so that finding missing modes is easier in the future. I'm not sure
about the t->rate stuff though, I didn't see an easy way to get that info
from fbdev.
Jesse
-------------- next part --------------
Name: kdrive-new-mode.patch
Type: text/x-diff
Size: 1737 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040726/4bb01eda/kdrive
-new-mode.bin
Date: Mon Jul 26 20:11:56 2004
Subject: [Xorg] more patch queue
Message-ID: <a728f9f904072620112328e077@mail.gmail.com>
I've got a few other patches I'd like to get some opinions on before I
commit them:
1. Add gamma correction support to the radeon video overlay. This
requires a new Xv attribute, XV_GAMMA. This should probably be
standardized since other drivers may want to expose it (assuming they
support it) and it would be nice to use the same controls across
multiple drivers. Since Xv attribute cannot be float values, I chose
to use integers that are 1000x the gamma value. so a gamma of 1.2
would be 1200, 2.2 would be 2200, etc. they can range from 0 to
5000. Does this seem reasonable, especially since no other drivers
currently expose gamma correction of the overlay.
2. merging the savage driver from DRI cvs. Besides experimental DRI
support, the savage driver in cvs also includes a few new features
over the old on in xorg cvs. It'd be nice to get these in for this
release. They include: dpms support for LCDs, interpolation on Xv
scaling, and many more fixes and clean ups. I also have dualhead
support (duoview) working for mobile savages, but it still has a few
bugs at the moment, so that'll have to wait.
Thanks,
Alex
Date: Mon Jul 26 21:27:46 2004
Subject: [Xorg] Re: tla migration
In-Reply-To: <1089501773.12812.5.camel@spiral.internal>
References: <1089501773.12812.5.camel@spiral.internal>
Message-ID: <20040727042744.GQ19305@fooishbar.org>
On Sat, Jul 10, 2004 at 07:22:53PM -0400, Andres Salomon wrote:
> I noticed in
> <http://freedesktop.org/pipermail/xorg/2004-July/001378.html>, you
> mentioned a tla-to-cvs gateway. I'd like to point out archzoom, which
> should obviate the need for such a thing. The software can be found
> here: <http://migo.sixbit.org/software/archzoom/>; I have the current
> release (0.2.3) running on
> <http://sloth.voxel.net/~dilinger/archzoom.cgi>, and the author has his
> current development release running on his site. The unenlightened
> (*g*) could simply go to archzoom and download a tarball of the latest
> dev tree, if they don't want to (or can't) do a tla get. Note that the
> feature is only in the dev tree; it's not in 0.2.3.
Awesome dude, cheers, I'll check it out.
Unfortunately, some people are attached to cvs with cvs log and all that
shit, and I'm going to have to present a pretty damn strong case to move
all of X, so I'll run with the gateway nevertheless.
That said, thanks for the info, and sorry it took so long to get back to
you. I'm really drowning in email here ...
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040727/996fb0c4/attach
ment-0001.pgp
Date: Mon Jul 26 21:28:27 2004
In-Reply-To: <40F5F774.F787CA09@nrubsig.org>
On Thu, Jul 15, 2004 at 05:18:12AM +0200, Roland Mainz wrote:
> Daniel:
> Is the patch OK for you ?
How important is it to you to get this up? If the answer is 'not
hugely', it might be better waiting a couple of weeks or so ...
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040727/e8f90bcc/attach
ment.pgp
Date: Tue Jul 27 02:23:06 2004
In-Reply-To: aplattner@nvidia.com wrote on Friday,
23 July 2004 at 16:38:11 -0700
References: <20040723233811.GA2813@dhcp-177-188.nvidia.com>
Aaron Plattner writes:
> Hello,
>
> Currently, there is no way for a driver to be notified of RandR events. This
> patch adds ScrnInfoRec functions which a driver can hook into to register whi
ch
> rotations are supported and be notified when RandR events happen. This is
> necessary mainly for hardware rotation support.
>
> There are a few bugs that occur when the screen is rotated 90 or 270 degrees.
A
> few functions compare pScreen->{width,height} to mode sizes, which is incorre
ct
> when the dimensions of the root window are swapped. This patch changes these
> functions to use virtualX and virtualY, which are not swapped in rotated mode
s.
> This bug also affects drivers such as nv and fbdev that support the "Rotate"
> option in the config file. (To reproduce, use nv with 'Option "Rotate" "CW"'
> and then try using Ctrl-Alt-+ and -).
>
> -- Aaron Plattner
>
Aaron,
Thank you for your patch! I would like to make a few comments:
1. Only drivers that support rotation entirely in HW would benefit from this
extension. About a year ago I have tried implementing a software solution
taking advantage of the layer code. I failed as the layer code is not
able to deal with the private structures to the drawables that each function
in the rendering layer can allocate in a graceful way:
When layers are switched a different chain of functions is called. This
may leave some privates unallocated which will be used in a different layer
(from a different rotation).
I did not investigate further on this issue as the plan is to handle screen
rotation when doing the screen composition in the long run.
We should explore how your proposed changes can fit into this picture.
2. There is no sample implementation in any of the X.Org drivers yet.
However to include a new functionality like this into the DDX I feel we
should have at least one sample implementation for an open source driver.
Maybe you can provide an implementation for the nv driver.
3. Also - and I admit this is a question of personal taste - should we use up
two function slots in the ScrnInfoRec structure for this or can we get by
with just one that is used both for query and setup?
Cheers,
Egbert.

> Index: hw/xfree86/common/xf86Cursor.c
> ===================================================================
> RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Cursor.c,v
> retrieving revision 1.1.1.2
> diff -u -r1.1.1.2 xf86Cursor.c
> --- hw/xfree86/common/xf86Cursor.c 25 Nov 2003 19:28:32 -0000 1.1.1.2
> +++ hw/xfree86/common/xf86Cursor.c 23 Jul 2004 22:29:21 -0000
> @@ -222,7 +222,7 @@
> if (mode == pScr->currentMode)
> return TRUE;
>
> - if (mode->HDisplay > pScreen->width || mode->VDisplay > pScreen->height)
> + if (mode->HDisplay > pScr->virtualX || mode->VDisplay > pScr->virtualY)
> return FALSE;
>
> pCursorScreen = miPointerCurrentScreen();
> Index: hw/xfree86/common/xf86Init.c
> ===================================================================
> RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Init.c,v
> diff -u -r1.2 xf86Init.c
> --- hw/xfree86/common/xf86Init.c 23 Apr 2004 19:20:32 -0000 1.2
> +++ hw/xfree86/common/xf86Init.c 23 Jul 2004 22:29:21 -0000
> @@ -897,6 +897,8 @@
> xf86Screens[i]->DPMSSet = NULL;
> xf86Screens[i]->LoadPalette = NULL;
> xf86Screens[i]->SetOverscan = NULL;
> + xf86Screens[i]->RRGetInfo = NULL;
> + xf86Screens[i]->RRSetConfig = NULL;
> scr_index = AddScreen(xf86Screens[i]->ScreenInit, argc, argv);
> if (scr_index == i) {
> /*
> Index: hw/xfree86/common/xf86RandR.c
> ===================================================================
> RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86RandR.c,v
> diff -u -r1.2 xf86RandR.c
> --- hw/xfree86/common/xf86RandR.c 23 Apr 2004 19:20:32 -0000 1.2
> +++ hw/xfree86/common/xf86RandR.c 23 Jul 2004 22:29:21 -0000
> @@ -38,6 +38,7 @@
> CloseScreenProcPtr CloseScreen;
> int virtualX;
> int virtualY;
> + Rotation rotation;
> } XF86RandRInfoRec, *XF86RandRInfoPtr;
>
> static int xf86RandRIndex;
> @@ -77,8 +78,8 @@
> return FALSE;
> RRRegisterRate (pScreen, pSize, refresh);
> if (mode == scrp->currentMode &&
> - mode->HDisplay == pScreen->width && mode->VDisplay == pScreen->heigh
t)
> - RRSetCurrentConfig (pScreen, RR_Rotate_0, refresh, pSize);
> + mode->HDisplay == scrp->virtualX && mode->VDisplay == scrp->virtualY
)
> + RRSetCurrentConfig (pScreen, randrp->rotation, refresh, pSize);
> if (mode->next == scrp->modes)
> break;
> }
> @@ -93,12 +94,17 @@
> if (!pSize)
> return FALSE;
> RRRegisterRate (pScreen, pSize, refresh0);
> - if (pScreen->width == randrp->virtualX &&
> - pScreen->height == randrp->virtualY)
> + if (scrp->virtualX == randrp->virtualX &&
> + scrp->virtualY == randrp->virtualY)
> {
> - RRSetCurrentConfig (pScreen, RR_Rotate_0, refresh0, pSize);
> + RRSetCurrentConfig (pScreen, randrp->rotation, refresh0, pSize);
> }
> }
> +
> + /* If there is driver support for randr, let it set our supported rotati
ons */
> + if(scrp->RRGetInfo)
> + return (*scrp->RRGetInfo)(scrp, rotations);
> +
> return TRUE;
> }
>
> @@ -125,8 +131,17 @@
> scrp->virtualX = mode->HDisplay;
> scrp->virtualY = mode->VDisplay;
> }
> - pScreen->width = scrp->virtualX;
> - pScreen->height = scrp->virtualY;
> + if(randrp->rotation & (RR_Rotate_90 | RR_Rotate_270))
> + {
> + /* If the screen is rotated 90 or 270 degrees, swap the sizes. */
> + pScreen->width = scrp->virtualY;
> + pScreen->height = scrp->virtualX;
> + }
> + else
> + {
> + pScreen->width = scrp->virtualX;
> + pScreen->height = scrp->virtualY;
> + }
> if (!xf86SwitchMode (pScreen, mode))
> {
> scrp->virtualX = pScreen->width = oldWidth;
> @@ -160,6 +175,8 @@
> int px, py;
> Bool useVirtual = FALSE;
>
> + randrp->rotation = rotation;
> +
> miPointerPosition (&px, &py);
> for (mode = scrp->modes; ; mode = mode->next)
> {
> @@ -179,6 +196,12 @@
> return FALSE;
> }
> }
> +
> + /* Have the driver do its thing. */
> + if (scrp->RRSetConfig &&
> + !(*scrp->RRSetConfig)(scrp, rotation, rate, pSize->width, pSize->hei
ght))
> + return FALSE;
> +
> if (!xf86RandRSetMode (pScreen, mode, useVirtual))
> return FALSE;
> /*
> @@ -189,6 +212,7 @@
> if (px < pSize->width && py < pSize->height)
> (*pScreen->SetCursorPosition) (pScreen, px, py, FALSE);
> }
> +
> return TRUE;
> }
>
> @@ -277,6 +301,8 @@
> randrp->CloseScreen = pScreen->CloseScreen;
> pScreen->CloseScreen = xf86RandRCloseScreen;
>
> + randrp->rotation = RR_Rotate_0;
> +
> pScreen->devPrivates[xf86RandRIndex].ptr = randrp;
> return TRUE;
> }
> Index: hw/xfree86/common/xf86str.h
> ===================================================================
> RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86str.h,v
> retrieving revision 1.1.1.2
> diff -u -r1.1.1.2 xf86str.h
> --- hw/xfree86/common/xf86str.h 25 Nov 2003 19:28:33 -0000 1.1.1.2
> +++ hw/xfree86/common/xf86str.h 23 Jul 2004 22:29:22 -0000
> @@ -476,7 +476,7 @@
> /* These values should be adjusted when new fields are added to ScrnInfoRec
*/
> #define NUM_RESERVED_INTS 16
> #define NUM_RESERVED_POINTERS 15
> -#define NUM_RESERVED_FUNCS 12
> +#define NUM_RESERVED_FUNCS 10
>
> typedef pointer (*funcPointer)(void);
>
> @@ -767,6 +767,8 @@
> typedef void xf86DPMSSetProc (ScrnInfoPtr, int, int);
> typedef void xf86LoadPaletteProc (ScrnInfoPtr, int, int *, LOCO *, VisualP
tr);
> typedef void xf86SetOverscanProc (ScrnInfoPtr, int);
> +typedef Bool xf86RRGetInfoProc (ScrnInfoPtr, unsigned short *);
> +typedef Bool xf86RRSetConfigProc (ScrnInfoPtr, int, int, int, int);
>
> /*
> * ScrnInfoRec
> @@ -921,6 +923,8 @@
> xf86DPMSSetProc *DPMSSet;
> xf86LoadPaletteProc *LoadPalette;
> xf86SetOverscanProc *SetOverscan;
> + xf86RRGetInfoProc *RRGetInfo;
> + xf86RRSetConfigProc *RRSetConfig;
>
> /*
> * This can be used when the minor ABI version is incremented.
> _______________________________________________
> xorg mailing list
Date: Tue Jul 27 04:40:30 2004
In-Reply-To: <20040727042818.GR19305@fooishbar.org>
<20040727042818.GR19305@fooishbar.org>
Message-ID: <41063F29.5090301@toya.net.pl>
Daniel Stone wrote:
> On Thu, Jul 15, 2004 at 05:18:12AM +0200, Roland Mainz wrote:
>
>>Daniel:
>>Is the patch OK for you ?
>
> How important is it to you to get this up? If the answer is 'not
> hugely', it might be better waiting a couple of weeks or so ...
I wrote a spec file for PLD with this patch included, so I'm not in a hurry.
It's just that I wanted to share my work so people using other distros
than PLD can use it. :)
--
Regards,
Jakub Piotr C?apa
Date: Tue Jul 27 06:29:11 2004
References: <20040723233811.GA2813@dhcp-177-188.nvidia.com>
<16646.7616.512992.811359@xf11.fra.suse.de>
Message-ID: <a728f9f904072706294095c2f8@mail.gmail.com>
On Tue, 27 Jul 2004 11:17:52 +0200, Egbert Eich
<eich@pdx.freedesktop.org> wrote:
> Aaron Plattner writes:
> > Hello,
> >
> > Currently, there is no way for a driver to be notified of RandR events. Th
is
> > patch adds ScrnInfoRec functions which a driver can hook into to register w
hich
> > rotations are supported and be notified when RandR events happen. This is
> > necessary mainly for hardware rotation support.
> >
> > There are a few bugs that occur when the screen is rotated 90 or 270 degree
s. A
> > few functions compare pScreen->{width,height} to mode sizes, which is incor
rect
> > when the dimensions of the root window are swapped. This patch changes the
se
> > functions to use virtualX and virtualY, which are not swapped in rotated mo
des.
> > This bug also affects drivers such as nv and fbdev that support the "Rotate
"
> > option in the config file. (To reproduce, use nv with 'Option "Rotate" "CW
"'
> > and then try using Ctrl-Alt-+ and -).
> >
> > -- Aaron Plattner
> >
>
> Aaron,
>
> Thank you for your patch! I would like to make a few comments:
>
> 1. Only drivers that support rotation entirely in HW would benefit from this
> extension. About a year ago I have tried implementing a software solution
> taking advantage of the layer code. I failed as the layer code is not
> able to deal with the private structures to the drawables that each function
> in the rendering layer can allocate in a graceful way:
> When layers are switched a different chain of functions is called. This
> may leave some privates unallocated which will be used in a different layer
> (from a different rotation).
> I did not investigate further on this issue as the plan is to handle screen
> rotation when doing the screen composition in the long run.
> We should explore how your proposed changes can fit into this picture.
>
> 2. There is no sample implementation in any of the X.Org drivers yet.
> However to include a new functionality like this into the DDX I feel we
> should have at least one sample implementation for an open source driver.
> Maybe you can provide an implementation for the nv driver.
I thought the smi driver supported this as a driver specific option.
If not, the complete databooks for smi chips are available on their
website:
http://www.siliconmotion.com
Alex
>
> 3. Also - and I admit this is a question of personal taste - should we use up
> two function slots in the ScrnInfoRec structure for this or can we get by
> with just one that is used both for query and setup?
>
> Cheers,
> Egbert.
>
> > Index: hw/xfree86/common/xf86Cursor.c
> > ===================================================================
> > RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Cursor.c,v
> > retrieving revision 1.1.1.2
> > diff -u -r1.1.1.2 xf86Cursor.c
> > --- hw/xfree86/common/xf86Cursor.c 25 Nov 2003 19:28:32 -0000 1.1.1.
2
> > +++ hw/xfree86/common/xf86Cursor.c 23 Jul 2004 22:29:21 -0000
> > @@ -222,7 +222,7 @@
> > if (mode == pScr->currentMode)
> > return TRUE;
> >
> > - if (mode->HDisplay > pScreen->width || mode->VDisplay > pScreen->height)
> > + if (mode->HDisplay > pScr->virtualX || mode->VDisplay > pScr->virtualY)
> > return FALSE;
> >
> > pCursorScreen = miPointerCurrentScreen();
> > Index: hw/xfree86/common/xf86Init.c
> > ===================================================================
> > RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Init.c,v
> > diff -u -r1.2 xf86Init.c
> > --- hw/xfree86/common/xf86Init.c 23 Apr 2004 19:20:32 -0000 1.2
> > +++ hw/xfree86/common/xf86Init.c 23 Jul 2004 22:29:21 -0000
> > @@ -897,6 +897,8 @@
> > xf86Screens[i]->DPMSSet = NULL;
> > xf86Screens[i]->LoadPalette = NULL;
> > xf86Screens[i]->SetOverscan = NULL;
> > + xf86Screens[i]->RRGetInfo = NULL;
> > + xf86Screens[i]->RRSetConfig = NULL;
> > scr_index = AddScreen(xf86Screens[i]->ScreenInit, argc, argv);
> > if (scr_index == i) {
> > /*
> > Index: hw/xfree86/common/xf86RandR.c
> > ===================================================================
> > RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86RandR.c,v
> > diff -u -r1.2 xf86RandR.c
> > --- hw/xfree86/common/xf86RandR.c 23 Apr 2004 19:20:32 -0000 1.2
> > +++ hw/xfree86/common/xf86RandR.c 23 Jul 2004 22:29:21 -0000
> > @@ -38,6 +38,7 @@
> > CloseScreenProcPtr CloseScreen;
> > int virtualX;
> > int virtualY;
> > + Rotation rotation;
> > } XF86RandRInfoRec, *XF86RandRInfoPtr;
> >
> > static int xf86RandRIndex;
> > @@ -77,8 +78,8 @@
> > return FALSE;
> > RRRegisterRate (pScreen, pSize, refresh);
> > if (mode == scrp->currentMode &&
> > - mode->HDisplay == pScreen->width && mode->VDisplay == pScreen->hei
ght)
> > - RRSetCurrentConfig (pScreen, RR_Rotate_0, refresh, pSize);
> > + mode->HDisplay == scrp->virtualX && mode->VDisplay == scrp->virtua
lY)
> > + RRSetCurrentConfig (pScreen, randrp->rotation, refresh, pSize);
> > if (mode->next == scrp->modes)
> > break;
> > }
> > @@ -93,12 +94,17 @@
> > if (!pSize)
> > return FALSE;
> > RRRegisterRate (pScreen, pSize, refresh0);
> > - if (pScreen->width == randrp->virtualX &&
> > - pScreen->height == randrp->virtualY)
> > + if (scrp->virtualX == randrp->virtualX &&
> > + scrp->virtualY == randrp->virtualY)
> > {
> > - RRSetCurrentConfig (pScreen, RR_Rotate_0, refresh0, pSize);
> > + RRSetCurrentConfig (pScreen, randrp->rotation, refresh0, pSize);
> > }
> > }
> > +
> > + /* If there is driver support for randr, let it set our supported rota
tions */
> > + if(scrp->RRGetInfo)
> > + return (*scrp->RRGetInfo)(scrp, rotations);
> > +
> > return TRUE;
> > }
> >
> > @@ -125,8 +131,17 @@
> > scrp->virtualX = mode->HDisplay;
> > scrp->virtualY = mode->VDisplay;
> > }
> > - pScreen->width = scrp->virtualX;
> > - pScreen->height = scrp->virtualY;
> > + if(randrp->rotation & (RR_Rotate_90 | RR_Rotate_270))
> > + {
> > + /* If the screen is rotated 90 or 270 degrees, swap the sizes. */
> > + pScreen->width = scrp->virtualY;
> > + pScreen->height = scrp->virtualX;
> > + }
> > + else
> > + {
> > + pScreen->width = scrp->virtualX;
> > + pScreen->height = scrp->virtualY;
> > + }
> > if (!xf86SwitchMode (pScreen, mode))
> > {
> > scrp->virtualX = pScreen->width = oldWidth;
> > @@ -160,6 +175,8 @@
> > int px, py;
> > Bool useVirtual = FALSE;
> >
> > + randrp->rotation = rotation;
> > +
> > miPointerPosition (&px, &py);
> > for (mode = scrp->modes; ; mode = mode->next)
> > {
> > @@ -179,6 +196,12 @@
> > return FALSE;
> > }
> > }
> > +
> > + /* Have the driver do its thing. */
> > + if (scrp->RRSetConfig &&
> > + !(*scrp->RRSetConfig)(scrp, rotation, rate, pSize->width, pSize->h
eight))
> > + return FALSE;
> > +
> > if (!xf86RandRSetMode (pScreen, mode, useVirtual))
> > return FALSE;
> > /*
> > @@ -189,6 +212,7 @@
> > if (px < pSize->width && py < pSize->height)
> > (*pScreen->SetCursorPosition) (pScreen, px, py, FALSE);
> > }
> > +
> > return TRUE;
> > }
> >
> > @@ -277,6 +301,8 @@
> > randrp->CloseScreen = pScreen->CloseScreen;
> > pScreen->CloseScreen = xf86RandRCloseScreen;
> >
> > + randrp->rotation = RR_Rotate_0;
> > +
> > pScreen->devPrivates[xf86RandRIndex].ptr = randrp;
> > return TRUE;
> > }
> > Index: hw/xfree86/common/xf86str.h
> > ===================================================================
> > RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/common/xf86str.h,v
> > retrieving revision 1.1.1.2
> > diff -u -r1.1.1.2 xf86str.h
> > --- hw/xfree86/common/xf86str.h 25 Nov 2003 19:28:33 -0000 1.1.1.
2
> > +++ hw/xfree86/common/xf86str.h 23 Jul 2004 22:29:22 -0000
> > @@ -476,7 +476,7 @@
> > /* These values should be adjusted when new fields are added to ScrnInfoRe
c */
> > #define NUM_RESERVED_INTS 16
> > #define NUM_RESERVED_POINTERS 15
> > -#define NUM_RESERVED_FUNCS 12
> > +#define NUM_RESERVED_FUNCS 10
> >
> > typedef pointer (*funcPointer)(void);
> >
> > @@ -767,6 +767,8 @@
> > typedef void xf86DPMSSetProc (ScrnInfoPtr, int, int);
> > typedef void xf86LoadPaletteProc (ScrnInfoPtr, int, int *, LOCO *, Visua
lPtr);
> > typedef void xf86SetOverscanProc (ScrnInfoPtr, int);
> > +typedef Bool xf86RRGetInfoProc (ScrnInfoPtr, unsigned short *);
> > +typedef Bool xf86RRSetConfigProc (ScrnInfoPtr, int, int, int, int
);
> >
> > /*
> > * ScrnInfoRec
> > @@ -921,6 +923,8 @@
> > xf86DPMSSetProc *DPMSSet;
> > xf86LoadPaletteProc *LoadPalette;
> > xf86SetOverscanProc *SetOverscan;
> > + xf86RRGetInfoProc *RRGetInfo;
> > + xf86RRSetConfigProc *RRSetConfig;
> >
> > /*
> > * This can be used when the minor ABI version is incremented.
> > _______________________________________________
> _______________________________________________
> xorg mailing list
>
From tim at birdsnest.maths.tcd.ie Tue Jul 27 09:15:07 2004
From: tim at birdsnest.maths.tcd.ie (Timothy Murphy)
Date: Tue Jul 27 09:26:20 2004
Subject: [Xorg] Please help Xorg newbie
Message-ID: <200407271715.09484.tim@birdsnest.maths.tcd.ie>
I'm looking for some low-level help with Xorg,
and don't know where to turn.
(It is clear that this mailing list is far too elevated for my problem!)
The problem: I'm running Fedora-2 on a Sony Picturebook (C1VFK) laptop,
and I cannot get X to run at 16bpp, as it did under Redhat-9.
I've looked at the FAQ <http://freedesktop.org/XOrg/FAQ>
and followed the advice there without getting very far.
Basically, if I set the DefaultDepth to 16bpp (or 15bpp)
when X starts there is a large black oval on the screen
which gradually disappears, leaving a white screen with nothing on it.
However, there is no X error reported in Xorg.0.log, or elsewhere.
I'd be happy to try my hand at compiling the ATI driver
but I'm not really sure where to start,
and am looking, as I said, for some low-level tutorial on Xorg.
For example, I wondered if it was possible to abstract the commands
sent to the video card, in which case it might be possible
to see how the commands differed from those sent by XFree86 under RH-9.
I should say that I filed a bugzilla (#718) about this problem
a couple of months ago,
but haven't heard anything from that.
Also, there has been some discussion of this issue
on the Picturebook mailing lists
<c1-forum@frijoles.hungry.com> and <vaio-pcg-c1-general@lists.sourceforge.net>
and it seems no-one has solved this problem.
I've asked about this problem on this list a couple of times,
without getting any response,
so I would be very grateful for any advice you can give me.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
From Jim.Gettys at hp.com Tue Jul 27 10:04:07 2004
Date: Tue Jul 27 10:04:15 2004
Subject: [Xorg] Xorg Tinderbox & firewalls
In-Reply-To: <4105AFD3.3080105@Sun.COM>
References: <003601c47327$7a7715c0$1e01a8c0@cnt496> <4105AFD3.3080105@Sun.COM>
Having firewall support would be very good.
On Mon, 2004-07-26 at 21:28, Alan Coopersmith wrote:
> In order to get tinderbox running through our firewall (which requires
> http proxy servers for http and socks proxies for cvs) I had to make
> two simple changes to the tinderbox scripts.
>
> The first I think is safe to go in the default since it simply checks
> the environment for http_proxy settings:
>
> --- /net/alf/export/alanc/X.org/tb/tinderclient/tinderclient.pl Mon Mar 8 12:
10:25 2004
> +++ ./tinderclient.pl Sun Jul 25 22:13:41 2004
> @@ -204,6 +204,7 @@
> $this->{MACHINE_NAME} = $machine_name;
> # The user agent object
> $this->{UA} = new LWP::UserAgent;
> + $this->{UA}->env_proxy();
> $this->{UA}->agent("TinderboxClient/" . $TinderClient::PROTOCOL_VERSION);
> # the tinderclient.log out
> $this->{LOG_OUT} = undef;
>
> The second should probably be made configurable if it's added to the files
> in CVS, otherwise just noted in the instructions for anyone who wants to do
> this, since it adds "runsocks" to the CVS commands:
>
> --- /net/alf/export/alanc/X.org/tb/tinderclient/TinderClientModules/XMonolithi
c.pm Sat Jul 17 13:21:56 2004
> +++ ./TinderClientModules/XMonolithic.pm Sun Jul 25 22:14:21 2004
> @@ -45,11 +45,11 @@
> $hostdef = $hostdef . "#define CcCmd ccache gcc\n";
> $hostdef = $hostdef . "#define CplusplusCmd ccache g++\n";
> }
>
> # Build the cvs checkout cmd - note, the cvsroot variable must be set in
the
> # Tinderbox.
> - $checkout_cmd = "cvs -z3 -d $cvsroot co -P ";
> - $update_cmd = "cvs -z3 -d $cvsroot update -P ";
> + $checkout_cmd = "runsocks cvs -z3 -d $cvsroot co -P ";
> + $update_cmd = "runsocks cvs -z3 -d $cvsroot update -P ";
>
> if ($branch) {
> $checkout_cmd .= "-r$branch ";
>
If you make this configurable, there would be no problems adding this
to CVS.
- Jim
Date: Tue Jul 27 13:13:37 2004
Subject: [Xorg] tinderbox - usefull?
Message-ID: <0a5801c47416$3c15ca20$1e01a8c0@cnt496>
So my 3 boxes have been buzzing away...
http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test
cfk, cfk, mdk
glad to see the cygwin one has lots of green - seems like a good thing.
Apparently the other two are on fire. not sure if that is a good thing.
Should they be under Test or XMonolithic?
Should I be doing something about the red?
What is the proper way to take one off line?
Carl Karsten
From alexander.gottwald at s1999.tu-chemnitz.de Tue Jul 27 13:41:16 2004
Date: Tue Jul 27 13:41:21 2004
In-Reply-To: <0a5801c47416$3c15ca20$1e01a8c0@cnt496>
References: <0a5801c47416$3c15ca20$1e01a8c0@cnt496>
On Tue, 27 Jul 2004, Carl Karsten wrote:
> So my 3 boxes have been buzzing away...
>
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test
>
> cfk, cfk, mdk
>
> glad to see the cygwin one has lots of green - seems like a good thing.
unfortunatly not. make does not stop after an error.
I've seen at least these errors:
- bison is not present
- flex is not present
- xc/lib/windows was not checked out
- xc/programs was not checked out properly
but as long as make does not stop after an error the tinderbox is quite useless.
It always shows green and no one notices it failed actually.
I think you can disable it again. But thanks for trying it anyway.
bye
ago
--
From Alexander.Gottwald at s1999.tu-chemnitz.de Tue Jul 27 13:49:13 2004
From: Alexander.Gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Tue Jul 27 13:49:38 2004
Message-ID: <Pine.LNX.4.55.0407272245540.31617@lupus.ago.vpn>
Carl Karsten wrote:
> Apparently the other two are on fire. not sure if that is a good thing.
libfreetype2 is too old.
To see if everything else builds you can change HasFreetype2 to NO in the
configfiles.
bye
ago
NP: Oomph! - Ice-Coffin
--
Alexander.Gottwald@informatik.tu-chemnitz.de
From Jim.Gettys at hp.com Tue Jul 27 13:51:13 2004
Date: Tue Jul 27 13:51:18 2004
On Tue, 2004-07-27 at 16:13, Carl Karsten wrote:
> So my 3 boxes have been buzzing away...
>
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test
>
> cfk, cfk, mdk
>
> glad to see the cygwin one has lots of green - seems like a good thing.
>
> Apparently the other two are on fire. not sure if that is a good thing.
>
> Should they be under Test or XMonolithic?
Test is intended for testing tinderbox.
When we're set to test modular builds, we should make another tinderbox.
>
> Should I be doing something about the red?
Go look at the logs that have been uploaded, and fix bugs :-).
>
> What is the proper way to take one off line?
>
One logs in as administrator, and messes with that one (for example,
if it is never going to reappear, deleting it entirely).
Note that various options can be passed from the tinderbox server
to the clients (so, for example, you can tell it to build a branch
of CVS, rather than head).
On the client side, you just kill the client...
- Jim
From Alexander.Gottwald at s1999.tu-chemnitz.de Tue Jul 27 14:37:33 2004
Date: Tue Jul 27 14:38:47 2004
> On Tue, 27 Jul 2004, Carl Karsten wrote:
>
> > So my 3 boxes have been buzzing away...
> >
> > http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=Test
> >
> > cfk, cfk, mdk
> >
> > glad to see the cygwin one has lots of green - seems like a good thing.
>
> unfortunatly not. make does not stop after an error.
>
> I've seen at least these errors:
>
> - bison is not present
> - flex is not present
> - xc/lib/windows was not checked out
> - xc/programs was not checked out properly
>
> but as long as make does not stop after an error the tinderbox is quite
> useless. It always shows green and no one notices it failed actually.
I fixed this in cvs. make will now stop after a target failed.
The issues with bison and flex is still open. I'm not sure about fontconfig,
expat and zlib. these are needed too.
http://x.cygwin.com/docs/cg/prog-build-native.html has a list of required
packages.
and I don't know what the problem with incomplete checkout is. I'll take a
closer look at the logfile tomorrow.
bye
ago
NP: Cinema Strange - Aborginal Anemia
--
Date: Tue Jul 27 23:41:41 2004
Subject: [Xorg] Lots of dlloader-related fixes
Hash: SHA1
Lots of cleanups to get the video drivers working with the dlloader. Please
test on your favorite hardware, the patch touches around 25 drivers and I can
only test six or so. In particular, sunffb, mga, chips, and glint hardware
almost certainly need testing to make the overlay modes work.
I'd like to get this committed as soon as possible, but I'm afraid I won't
make the alpha freeze on Friday.
- - ajax
iD8DBQFBB0qZW4otUKDs0NMRAnNrAJ9W9t1VmfLOkahr2C+ewvE3I1cwHACgtpfP
zJqqwLVlQ9nt6QWcAtjl+9E=
=YOUi
Date: Wed Jul 28 03:46:33 2004
Subject: [Xorg] NEED_SCREEN_REGIONS
Is anyone aware of a server with NEED_SCREEN_REGIONS set? It would be
nice to be able to remove that code if not.
--
From carl at personnelware.com Wed Jul 28 05:03:39 2004
Date: Wed Jul 28 05:03:33 2004
<Pine.LNX.4.55.0407272245540.31617@lupus.ago.vpn>
Message-ID: <0e1901c4749a$ebc94bc0$1e01a8c0@cnt496>
To anyone I have replied personally to, sorry - keep forgetting that posts from
this list are not "from: this list"
cygwin - I think I have everything downloaded and installed (doh, forgot the
install part last night.)
linux -
>
> To see if everything else builds you can change HasFreetype2 to NO in the
> configfiles.
Given that everything gets blown away:
<--- TINDERBOX FINISHED (SUCCESS) RUNNING 'rm -rf
'/home/carl/src/tinderclient/XMonolithic/xc'' Wed, 28 Jul 2004 07:04:55 GMTWhere
should I put the config?>> >> What is the proper way to take one off line? >>
>One logs in as administrator, and messes with that one (for example,>if it is
never going to reappear, deleting it entirely).I guess adding a version number
to the box name was a bad idea because now I have 'old' ones that are never
going to reappear. Sorry bout that. Carl K
From elanthis at awesomeplay.com Wed Jul 28 07:56:31 2004
Date: Wed Jul 28 07:56:37 2004
Subject: [Xorg] anti-x11 response
Hi all,
I was wondering if there are any official or semi-official well-written
rebuttals to things like Fresco's "Fresco vs X11" page
(http://wiki.fresco.org/FrescoVsX) or the Y-Windows explanation of why
X11 is out-dated? I'm just thinking it'd be nice to have the URL of a
good write-up to point people to when trying to explain X11 to people
that've been brainwashed and believe the misinformation or outright lies
certain other projects try to spread.
Thanks,
--
Date: Wed Jul 28 10:22:37 2004
References: <1091026590.1042.20.camel@support02.civic.twp.ypsilanti.mi.us>
well we do need to improve the networking to be more efficient
like they say,
and I'm not so sure trying to push a unified widget standard is such a bad
idea.
adding unified unicode/bidi support is not such a bad idea, even if it
breaks few old programs still moving everything to unicode is something
which must be done at some point. (maybe even in xkb?)
Alpha blending would only be added next release.
so their anti-x11 thing is not THAT not true..
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 28 Jul 2004, Sean Middleditch wrote:
> Hi all,
>
> I was wondering if there are any official or semi-official well-written
> rebuttals to things like Fresco's "Fresco vs X11" page
> (http://wiki.fresco.org/FrescoVsX) or the Y-Windows explanation of why
> X11 is out-dated? I'm just thinking it'd be nice to have the URL of a
> good write-up to point people to when trying to explain X11 to people
> that've been brainwashed and believe the misinformation or outright lies
> certain other projects try to spread.
>
> Thanks,
> --
>
> _______________________________________________
> xorg mailing list
>
Date: Wed Jul 28 10:25:26 2004
<20040712082239.GN12023@fooishbar.org>
<1090174789.5643.1.camel@linux.site>
Hey,
I saw on adam's email that xorg getting into alpha phaze/freature freeze
soon, Where can I obtain that sort of information?
Would it be possible to send those dates to this list as well?
btw with the release comming may I mention again the community part?
(forum,janitor,docs and the sort), it would be really ashame to miss this
oppertunity...
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Mon, 19 Jul 2004, Jim Gettys wrote:
> On Sun, 2004-07-11 at 21:22, an unknown sender wrote:
> > On Sun, Jul 11, 2004 at 04:16:59PM +0300, Ely Levy wrote:
> > > And what about the move to XCB?
From reed at reedmedia.net Wed Jul 28 10:30:59 2004
Date: Wed Jul 28 10:31:40 2004
On Wed, 28 Jul 2004, Ely Levy wrote:
> I saw on adam's email that xorg getting into alpha phaze/freature freeze
> soon, Where can I obtain that sort of information?
> Would it be possible to send those dates to this list as well?
http://freedesktop.org/bin/view/XOrg/XorgReleasePlan#Deadlines
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
From nbensa at gmx.net Wed Jul 28 10:29:48 2004
From: nbensa at gmx.net (Norberto Bensa)
Date: Wed Jul 28 10:56:19 2004
Message-ID: <200407281429.48209.nbensa@gmx.net>
Hello,
Ely Levy wrote:
> Alpha blending would only be added next release.
Which one?
The release planned for august 25th, or one after that?
Thanks,
Norberto
From rogelio at smsglobal.net Wed Jul 28 11:04:28 2004
From: rogelio at smsglobal.net (Rogelio M.Serrano Jr.)
Date: Wed Jul 28 11:04:32 2004
Subject: [Xorg] anti-x11 response (fwd)
Message-ID: <b2e614bd51dd8442df24e5d5d9857c86@master>
---------- Forwarded message ----------
Date: 2004-07-29 01:35:27 +0800
From: Rogelio M. Serrano Jr. <rogelio@smsglobal.net>
Subject: Re: [Xorg] anti-x11 response
On 2004-07-29 01:22:34 +0800 Ely Levy <elylevy-xserver@cs.huji.ac.il>
wrote:
> well we do need to improve the networking to be more efficient
> like they say,
> and I'm not so sure trying to push a unified widget standard is such
> a bad
> idea.
> adding unified unicode/bidi support is not such a bad idea, even if it
> breaks few old programs still moving everything to unicode is
> something
> which must be done at some point. (maybe even in xkb?)
>
> Alpha blending would only be added next release.
> so their anti-x11 thing is not THAT not true..
>
>
> Ely Levy
> System group
> Hebrew University
> Jerusalem Israel
>
>
>
> On Wed, 28 Jul 2004, Sean Middleditch wrote:
>
>> Hi all,
>>
>> I was wondering if there are any official or semi-official
>> well-written
>> rebuttals to things like Fresco's "Fresco vs X11" page
>> (http://wiki.fresco.org/FrescoVsX) or the Y-Windows explanation of
>> why
>> X11 is out-dated? I'm just thinking it'd be nice to have the URL of
>> a
>> good write-up to point people to when trying to explain X11 to people
>> that've been brainwashed and believe the misinformation or outright
>> lies
>> certain other projects try to spread.
>>
>> Thanks,
>> --
>> Sean Middleditch <elanthis@awesomeplay.com>
>> AwesomePlay Productions, Inc.
>>
>> _______________________________________________
>> xorg mailing list
>> xorg@freedesktop.org
>> http://freedesktop.org/mailman/listinfo/xorg
>>
> _______________________________________________
> xorg mailing list
>
Xorg is going in the right direction but i still find it hard to
understand xserver code to able to do something meanigful. Even if i
have done janitor stuff on my own. Still cant reconcile the theory
with actual implementation. Im beginning to think that trying to
implement my own understanding of the theory and cmparing to the
actual code will yield better understanding.
Date: Wed Jul 28 11:06:39 2004
In-Reply-To: <Pine.LNX.4.43.0407281027580.24109-100000@pilchuck.reedmedia.net>
References: <Pine.LNX.4.43.0407281027580.24109-100000@pilchuck.reedmedia.net>
Hey,
I see there is 12 days between beta and release?
Since there arent even home packagers it would preety much mean
not many people would get to test the release at all.
Talking on irc I got the impression some people think
release doesn't mean that the code is stable, I hope it's not the general
idea?
Wouldn't it make more sense to give it a bit more time?
Orginize the testers?get packagers?and then give normal users
2 weeks from the package release for major plaforms to test the package
and then release.
if we are not intending for the release to be stable maybe we should
make development branch like 6.8.x till it's stable and everyone is happy
and then release 6.9 this way we can release without hurting xorg's
reputation of being stable.
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 28 Jul 2004, Jeremy C. Reed wrote:
> On Wed, 28 Jul 2004, Ely Levy wrote:
>
> > I saw on adam's email that xorg getting into alpha phaze/freature freeze
> > soon, Where can I obtain that sort of information?
> > Would it be possible to send those dates to this list as well?
>
> http://freedesktop.org/bin/view/XOrg/XorgReleasePlan#Deadlines
>
> Jeremy C. Reed
>
> BSD News, BSD tutorials, BSD links
> http://www.bsdnewsletter.com/
>
>
>
Date: Wed Jul 28 11:45:51 2004
Subject: [Xorg] tinderboxs need tweeks
Message-ID: <10ca01c474d3$1f1fdd80$1e01a8c0@cnt496>
Got 4 boxes now. - yea knoppix (almost works out of the box - had to mount a
drive because I didn't have 800mb of ram.)
http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
cfk.w2k.v2-cygwin1.5.1 back to green, looks like the compile finished. Now is
it good?
All 3 Linux boxes are red :
cfk.mdk.v3-Linux2.6.3
cfk.gt.v3-Linux2.6.7-bk20-i810
cfk.sahara.knoppix3.4
I'm not sure what they need - if someone could check out the log and let me
know, I'll be happy to adjust them.
Carl K
Date: Wed Jul 28 12:20:56 2004
In-Reply-To: Your message of "Wed, 28 Jul 2004 03:46:29 PDT."
<1091011588.897.263.camel@leguin>
Message-ID: <E1BptyB-00013O-Po@evo.keithp.com>
Around 3 o'clock on Jul 28, Eric Anholt wrote:
> Is anyone aware of a server with NEED_SCREEN_REGIONS set? It would be
> nice to be able to remove that code if not.
I haven't seen anyone use that for over 15 years. Does anyone else have
experience with this?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040728/0c3443c7/attach
ment.pgp
Date: Wed Jul 28 12:23:09 2004
In-Reply-To: <10ca01c474d3$1f1fdd80$1e01a8c0@cnt496>
References: <10ca01c474d3$1f1fdd80$1e01a8c0@cnt496>
On Wed, 28 Jul 2004, Carl Karsten wrote:
> Got 4 boxes now. - yea knoppix (almost works out of the box - had to mount a
> drive because I didn't have 800mb of ram.)
>
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
>
> cfk.w2k.v2-cygwin1.5.1 back to green, looks like the compile finished. Now i
s
> it good?
Great!
> All 3 Linux boxes are red :
>
> cfk.mdk.v3-Linux2.6.3
> cfk.gt.v3-Linux2.6.7-bk20-i810
> cfk.sahara.knoppix3.4
>
> I'm not sure what they need - if someone could check out the log and let me
> know, I'll be happy to adjust them.
cfk.gt.v3-Linux2.6.7-bk20-i810 and cfk.mdk.v3-Linux2.6.3 has old freetype.
Same problem as with nearly every os.
bye
ago
--
From bryce at osdl.org Wed Jul 28 12:41:21 2004
Date: Wed Jul 28 12:41:34 2004
On Wed, 28 Jul 2004, Alexander Gottwald wrote:
> On Wed, 28 Jul 2004, Carl Karsten wrote:
> > Got 4 boxes now. - yea knoppix (almost works out of the box - had to mount a
> > drive because I didn't have 800mb of ram.)
> >
> > http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
> >
> > cfk.w2k.v2-cygwin1.5.1 back to green, looks like the compile finished. Now
is
> > it good?
>
> Great!
>
> > All 3 Linux boxes are red :
> >
> > cfk.mdk.v3-Linux2.6.3
> > cfk.gt.v3-Linux2.6.7-bk20-i810
> > cfk.sahara.knoppix3.4
I've got a Debian unstable/testing box I'm partway through setting up
(hopefully it'll be ready in a few days; it's been a while since this
box had much attention.)
I've also got a "mystery box" that's dedicated for tinderbox builds but
isn't booting. I suspect it has some flavor of RedHat on it. Hopefully
I should have that in process by early next week, too.
Bryce
From Stuart.Kreitman at Sun.COM Wed Jul 28 12:38:49 2004
Date: Wed Jul 28 12:46:31 2004
In-Reply-To: <E1BptyB-00013O-Po@evo.keithp.com>
References: <E1BptyB-00013O-Po@evo.keithp.com>
Message-ID: <410800C9.7050407@sun.com>
would be nice if you could wait till after I put in a hack wrt DAMAGE.
skk
>Around 3 o'clock on Jul 28, Eric Anholt wrote:
>
>
>
>>Is anyone aware of a server with NEED_SCREEN_REGIONS set? It would be
>>nice to be able to remove that code if not.
>>
>>
>
>I haven't seen anyone use that for over 15 years. Does anyone else have
>experience with this?
>
>-keith
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>xorg mailing list
>xorg@freedesktop.org
>http://freedesktop.org/mailman/listinfo/xorg
>
>
From andy at nospam.com Wed Jul 28 16:18:36 2004
Date: Wed Jul 28 16:31:22 2004
Subject: [Xorg] A possible upgrade path for X (was Re: anti-x11 response)
Message-ID: <4108344C.30607@nospam.com>
Regardless of how many arguments are given against X, I believe
there is one major reason that you cannot really rebut against
and that is backwards compatibility. There are just so many useful
apps written in X that indeed, there would be more to lose than
to gain by not using it anymore.
However, thanks to X's network-transparent design, achieving
backwards compatibility is conceptually straightforward. You just
have to implement an X server running on any windowing system,
whether Aqua or Win32 or whatever and you've got your backwards
compatibility.
So if it is deemed that X's architecture is so outdated (certainly
not a conclusion that everyone shares) that it can't be properly
fixed / retrofitted, there is still a way to salvage all the old
X programs.
Two approaches come to mind:
1) Build a completely new windowing system from the ground up,
but implement an X server running on top of it.
2) Invent a server which uses an over-the-wire protocol that's
transparently backwards compatible with old X clients but can
be negotiated to switch to using a modern, streamlined one when
servicing newer clients. (i.e. a kind of backwards-compatibility
through encapsulation-of-older-subsystems approach which Microsoft
has proven works amazingly well in the case of Windows XP running
Win16 and DOS apps)
> Hi all,
>
> I was wondering if there are any official or semi-official well-written
> rebuttals to things like Fresco's "Fresco vs X11" page
> (http://wiki.fresco.org/FrescoVsX) or the Y-Windows explanation of why
> X11 is out-dated? I'm just thinking it'd be nice to have the URL of a
> good write-up to point people to when trying to explain X11 to people
> that've been brainwashed and believe the misinformation or outright lies
> certain other projects try to spread.
>
> Thanks,
--
Date: Wed Jul 28 17:48:28 2004
Subject: [Xorg] Chromium vs GLX protocol
Slashdot is saying that SGI is going to port their clustered ATI
graphics to Linux in the near future. The SGI page says this code is
based on Chromium. I've read that the network protocol of Chromium is
far better than the GLX protocol, especially in the area of state
management. Does anyone have experience with both protocols and can
comment on how they compare?
If the Chromium protocol really is a lot better would it make sense to
evaluate shifting our focus from GLX to the Chromium protocol? In the
long run the coming shift to things like X on GL and Glitz may
ultimately move a lot of network traffic from the X protocol to one of
the GL ones. If Chromium is significantly better wouldn't it be wiser
to change the X server GL protocol now rather than later?
http://linux.slashdot.org/article.pl?sid=04/07/28/1427228&tid=163&tid=139&tid=10
3
http://www.sgi.com/visualization/linux.html
http://chromium.sourceforge.net/
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
From idr at us.ibm.com Wed Jul 28 17:27:39 2004
Date: Wed Jul 28 17:49:28 2004
Subject: [Xorg] Update on video memory manager work
Message-ID: <4108447B.6020001@us.ibm.com>
Since there was so much interest at DDC, I wanted to give a brief update
of my memory manager work. I have about 95% of the baseline
functionality (i.e., what's required to just replace the existing
texture manager) done. When I was at DDC, I was still hitting a few
assertion failures, but, as of today, I've fixed all those.
I have hit one snag, but it's just a temporary set back. The best way
to explain is with an example. Keep in mind that the current texture
manager can (at least theoretically) also encounter this problem. Say
you have 32MB of memory and 3 texture units. Say the application wants
to bind a 16MB texture and two 8MB textures. Since 16 + 8 + 8 = 32, it
should fit, right? Well, the allocator selects the location to put a
texture based on a (driver supplied) cost function. For each allocation
it finds the location in memory with the least cost to put the texture.
Given that, it could put the first texture (say, one of the 8MB
textures) at offset 0, and the second (say, the other 8MB texture) at
0x00830000. Guess what? Now there's no 16MB chunk of memory for the
other texture.
So, I'm going to rework the interface a little bit so that the allocator
can look at all the require allocations at once. It will place them in
memory using some sort of path finding algorithm (probably A*). That
seems like a reasonably good fit. Who thought you'd need AI for a video
driver? ;)
Once I get that done, I'll have to find some way to reasonably
distribute the simulator for people to review.
Date: Wed Jul 28 19:10:22 2004
Subject: [Xorg] knoppix tinderbox
Message-ID: <139401c47510$818fada0$1e01a8c0@cnt496>

> I've also got a "mystery box" that's dedicated for tinderbox builds but
> isn't booting. I suspect it has some flavor of RedHat on it. Hopefully
> I should have that in process by early next week, too.
Knoppix26 2 (2.6 kernel, stop at runlevel 2 to save the memory for the
compiler.)
# ipconfig
# passwd root
# /etc/init.d/ssh start
Go back to desk, sit on comphy chair, ssh to knoppix box
Find about 800 meg of space, so mount a drive, unless this old box has about a
Gig of ram.
# mkreiserfs /dev/hda1
# cd /mnt/auto/hda1
# cvs -d :pserver:anoncvs@freedesktop.org:/cvs/sysadmin login
cvs login: warning: failed to open /root/.cvspass for reading: No such file or
directory
(I guess you can ignore that - the next line works.)
# cvs -d :pserver:anoncvs@freedesktop.org:/cvs/sysadmin co tinderclient
# vi ./tinderclient/run-client.sh
( set this to: export PERLLIB=/home/knoppix/tinderclient, change Test to
XMonolithic )
# screen ./tinderclient/run-client.sh you.yourbox.knoppix3.4
Disconnect the screen and have a beer.
Should get the same error that my cfk.sahara.knoppix3.4 box does, but at least
it will ready for active duty. Or maybe it will even be of value as is.
Carl K
Date: Wed Jul 28 19:17:05 2004
Subject: [Xorg] Debian/unstable tinderbox
In-Reply-To: <139401c47510$818fada0$1e01a8c0@cnt496>
Okay, I've got the Debian tinderclient running here at OSDL. Looks like
we have no shortage of tinderclients now. :-)
Bryce
On Wed, 28 Jul 2004, Carl Karsten wrote:
> > I've also got a "mystery box" that's dedicated for tinderbox builds but
> > isn't booting. I suspect it has some flavor of RedHat on it. Hopefully
> > I should have that in process by early next week, too.
>
> Knoppix26 2 (2.6 kernel, stop at runlevel 2 to save the memory for the
> compiler.)
>
> # ipconfig
> # passwd root
> # /etc/init.d/ssh start
>
> Go back to desk, sit on comphy chair, ssh to knoppix box
>
> Find about 800 meg of space, so mount a drive, unless this old box has about a
> Gig of ram.
> # mkreiserfs /dev/hda1
> # cd /mnt/auto/hda1
>
> # cvs -d :pserver:anoncvs@freedesktop.org:/cvs/sysadmin login
> cvs login: warning: failed to open /root/.cvspass for reading: No such file or
> directory
> (I guess you can ignore that - the next line works.)
>
> # cvs -d :pserver:anoncvs@freedesktop.org:/cvs/sysadmin co tinderclient
>
> # vi ./tinderclient/run-client.sh
> ( set this to: export PERLLIB=/home/knoppix/tinderclient, change Test to
> XMonolithic )
>
> # screen ./tinderclient/run-client.sh you.yourbox.knoppix3.4
>
> Disconnect the screen and have a beer.
>
> Should get the same error that my cfk.sahara.knoppix3.4 box does, but at least
> it will ready for active duty. Or maybe it will even be of value as is.
>
> Carl K
>
> _______________________________________________
> xorg mailing list
>
Date: Wed Jul 28 19:22:32 2004
Message-ID: <13a201c47512$e92c6b40$1e01a8c0@cnt496>
> >
> >
> > I'm not sure what they need - if someone could check out the log and let me
> > know, I'll be happy to adjust them.
>
> cfk.gt.v3-Linux2.6.7-bk20-i810 and cfk.mdk.v3-Linux2.6.3 has old freetype.
> Same problem as with nearly every os.
gentoo:
# qpkg -I -v | grep freetype
media-libs/freetype-2.1.5-r1 *
Still erroring:
making all in lib/font/FreeType...
make[5]: Entering directory `/home/carl/src/XMonolithic/xc/lib/font/FreeType'
rm -f xttcap.o unshared/xttcap.o
gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freety
pe2 -I/usr/include/freetype2/config -I. -I../../../include/fonts -I../include -I
../../../exports/include/X11 -I../../../programs/Xserver/include
-I../../../exports/include -I../../.. -I../../../exports/include -Dli
nux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX
_SOURCE -D_XOPEN_SOURCE
-DFUNCPROTO=15 -DNARROWPR
OTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH
-DXFreeXDGA -DXv
Extension -DXFree86LOADER -DXFree86Server
-DXF86VIDMODE -DXvMCExten
sion -DSMART_SCHEDULE
-DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_
LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000
) + ((7) * 100000) +
((0) * 1000) +
0)" -DXFREE86_FT2 -O2 -fno-strength-reduce -fno-strict-aliasing
xttcap.c -o unshared/xttcap.o
rm -f xttcap.o
gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall
-Wpointer-arith -Wundef -I/usr/include/freetype2 -I/usr/include/freetype2/conf
ig -I. -I../../../include/fonts -I../include -I../../../exports/include/X11
-I../../../programs/Xserver/include -I../../../exports/includ
e -I../../.. -I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=
199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE
-D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO
-DGCCUSESGAS -DAVOID_GLYPHB
LT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtensio
n -DXFree86LOADER -D
XFree86Server -DXF86VIDMODE
-DB
UILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_
ENDIAN -DXORG_VERSION_
CURRENT="(((6) * 10000000) + ((7) * 100000) + ((0) * 1000) +
-DXFREE86_FT2 -fPIC xttcap.c
rm -f ftfuncs.o unshared/ftfuncs.o
gcc -m32 -c -ansi -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freety
pe2 -I/usr/include/freetype2/config -I. -I../../../include/fonts -I../include -I
../../../exports/include/X11 -I../../../programs/Xserver/include
-I../../../exports/include -I../../.. -I../../../exports/include -Dli
nux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX
_SOURCE -D_XOPEN_SOURCE
-DFUNCPROTO=15 -DNARROWPR
OTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH
-DXFreeXDGA -DXv
Extension -DXFree86LOADER -DXFree86Server
-DXF86VIDMODE -DXvMCExten
sion -DSMART_SCHEDULE
-DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_
LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000
) + ((7) * 100000) +
((0) * 1000) +
0)" -DXFREE86_FT2 -O2 -fno-strength-reduce -fno-strict-aliasing
ftfuncs.c -o unshared/ftfuncs.o
make[5]: *** [ftfuncs.o] Error 1Sugestions?Carl K
From Jim.Gettys at hp.com Wed Jul 28 19:38:58 2004
Date: Wed Jul 28 19:39:02 2004
Actually,
If you do the math, we haven't even touched the tip of the iceberg.
We have N versions of *BSD, Linux, Solaris, Cygwin, Darwin etc, on x86,
x86-64, Itanium, ARM, Alpha, etc.
And that is not even testing the graphics cards in each.
The multiplicative explosion gets us to tens of thousands of
permutations.
So the more, the merrier (though we need to go at this somewhat
sytematically. We'll certainly need multiple tinderbox pages.
- Jim
On Wed, 2004-07-28 at 22:17, Bryce Harrington wrote:
> Okay, I've got the Debian tinderclient running here at OSDL. Looks like
> we have no shortage of tinderclients now. :-)
>
> http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
>
> Bryce
>
> On Wed, 28 Jul 2004, Carl Karsten wrote:
> > > I've also got a "mystery box" that's dedicated for tinderbox builds but
> > > isn't booting. I suspect it has some flavor of RedHat on it. Hopefully
> > > I should have that in process by early next week, too.
> >
> > Knoppix26 2 (2.6 kernel, stop at runlevel 2 to save the memory for the
> > compiler.)
> >
> > # ipconfig
> > # passwd root
> > # /etc/init.d/ssh start
> >
> > Go back to desk, sit on comphy chair, ssh to knoppix box
> >
> > Find about 800 meg of space, so mount a drive, unless this old box has about
a
> > Gig of ram.
> > # mkreiserfs /dev/hda1
> > # cd /mnt/auto/hda1
> >
> > # cvs -d :pserver:anoncvs@freedesktop.org:/cvs/sysadmin login
> > cvs login: warning: failed to open /root/.cvspass for reading: No such file
or
> > directory
> > (I guess you can ignore that - the next line works.)
> >
> > # cvs -d :pserver:anoncvs@freedesktop.org:/cvs/sysadmin co tinderclient
> >
> > # vi ./tinderclient/run-client.sh
> > ( set this to: export PERLLIB=/home/knoppix/tinderclient, change Test to
> > XMonolithic )
> >
> > # screen ./tinderclient/run-client.sh you.yourbox.knoppix3.4
> >
> > Disconnect the screen and have a beer.
> >
> > Should get the same error that my cfk.sahara.knoppix3.4 box does, but at lea
st
> > it will ready for active duty. Or maybe it will even be of value as is.
> >
> > Carl K
> >
> > _______________________________________________
> >
>
> _______________________________________________
> xorg mailing list
From reed at reedmedia.net Wed Jul 28 19:56:35 2004
Date: Wed Jul 28 19:56:41 2004
On Wed, 28 Jul 2004, Jim Gettys wrote:
> We have N versions of *BSD, Linux, Solaris, Cygwin, Darwin etc, on x86,
> x86-64, Itanium, ARM, Alpha, etc.
I possibly can help with NetBSD and other *BSDs.
I may have overlooked it, but where is the quick
how-to-get-started-with-tinderbox guide for Xorg?
I don't really know what tinderbox other than what I am beginning to read
at http://www.mozilla.org/tinderbox.html
NetBSD (as far as I know) doesn't have a packaged tinderbox client.
I also don't see a tinderbox client for FreeBSD (it is not in "ports"
collection).
Maybe I can package it for others once I find the source ...
Jeremy C. Reed
technical support & remote administration
http://www.pugetsoundtechnology.com/
From brian.paul at tungstengraphics.com Wed Jul 28 20:37:53 2004
Date: Wed Jul 28 20:40:15 2004
Message-ID: <41087111.3000402@tungstengraphics.com>
Jon Smirl wrote:
> Slashdot is saying that SGI is going to port their clustered ATI
> graphics to Linux in the near future. The SGI page says this code is
> based on Chromium. I've read that the network protocol of Chromium is
> far better than the GLX protocol, especially in the area of state
> management. Does anyone have experience with both protocols and can
> comment on how they compare?
Sure...
> If the Chromium protocol really is a lot better would it make sense to
> evaluate shifting our focus from GLX to the Chromium protocol? In the
> long run the coming shift to things like X on GL and Glitz may
> ultimately move a lot of network traffic from the X protocol to one of
> the GL ones. If Chromium is significantly better wouldn't it be wiser
> to change the X server GL protocol now rather than later?
The Chromium command packer packs GL commands more densely than GLX.
A one-byte opcode is used for most commands and operands are packed
tightly in memory. Opcodes are packed separate from the operands in a
unique way too.
Chromium also has a state tracking system which can eliminate
redundant commands from being packed/sent. It's pretty complicated
though and still a source of bugs.
I wouldn't say that Chromium's packer is a *lot* better than GLX. And
I wouldn't advocate switching to it. GLX interoperability is
important and making such a switch would upset that. I don't think
the effort to switch would be worth the trouble. Performance-wise, I
think the gains would be quite modest.
-Brian
Date: Wed Jul 28 20:58:36 2004
In-Reply-To: <Pine.LNX.4.43.0407281952160.24109-100000@pilchuck.reedmedia.net>
On Wed, 28 Jul 2004, Jeremy C. Reed wrote:
> On Wed, 28 Jul 2004, Jim Gettys wrote:
>
> > We have N versions of *BSD, Linux, Solaris, Cygwin, Darwin etc, on x86,
> > x86-64, Itanium, ARM, Alpha, etc.
>
> I possibly can help with NetBSD and other *BSDs.
>
> I may have overlooked it, but where is the quick
> how-to-get-started-with-tinderbox guide for Xorg?
http://www.freedesktop.org/Software/TinderboxWiki
This link is also in the tinderclient README. I added some additional
details on use of 'screen', etc. The tinderbox itself is here:
> I don't really know what tinderbox other than what I am beginning to read
> at http://www.mozilla.org/tinderbox.html
>
> NetBSD (as far as I know) doesn't have a packaged tinderbox client.
>
> I also don't see a tinderbox client for FreeBSD (it is not in "ports"
> collection).
>
> Maybe I can package it for others once I find the source ...
You check it out of CVS from freedesktop.org, and it has all the bits
you need. It's pretty straightforward to set up, and the instructions
are easy to follow step-by-step. There's not really many dependencies
to set up (except basics like cvs, perl, etc.)
Bryce
Date: Thu Jul 29 01:16:22 2004
Subject: [Xorg] New Render polygon semantics. New Render request
(RenderAddTraps)
Message-ID: <E1Bq65E-00054i-Ls@evo.keithp.com>
I've updated the proposed Render specification to include a more complete
specification for polygon rasterization using the regular point-sampling
grid discussed here earlier and to include a new AddTraps request using a
simplified interface and smaller trapezoid encoding.
The Xrender library has been updated to include the new request.
The X server source code for xserver.freedesktop.org includes a
preliminary implementation of the new semantics. Performance isn't great
yet, but I wanted to produce a brief implementation which was "obviously"
correct before moving on to a fancier more efficient algorithm.
The existing Trapezoids and Triangles requests use the new fill semantics,
so testing applications using those requests will help flush out any bugs
in the rasterization code. So far things are looking about the same, which
was expected.
As always, comments on the protocol specification would be especially
welcome; I'm hoping we're nearing the end of the Render extension
specification and can potentially bring that to a 1.0 release sometime
soon.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040729/97d9db60/attach
ment.pgp
From ufz6 at rz.uni-karlsruhe.de Thu Jul 29 03:14:02 2004
Date: Thu Jul 29 03:13:03 2004
Subject: [Xorg] Differences between Xorg and Xserver
Message-ID: <E1Bq7uE-0001Nl-00@mailgate.rz.uni-karlsruhe.de>
I noticed that both X implementations uses this mailing list. What the
differences between them. Is Xserver the feature X Implementation for Xorg?
We know NVIDIA Co has a kernel frame buffer for Linux, could we use it with
Xfbdev with Xserver(not Xorg)?
Amir Bukhari
From carl at personnelware.com Thu Jul 29 03:46:39 2004
Date: Thu Jul 29 03:46:40 2004
Message-ID: <165901c47559$547f3b20$1e01a8c0@cnt496>
> > http://freedesktop.org/cgi-bin/tinderbox3/showbuilds.pl?tree=XMonolithic
> >
> > cfk.w2k.v2-cygwin1.5.1 back to green, looks like the compile finished. Now
is
> > it good?
>
> Great!
In the past I have been able to compile but not run (server crashes right out
the door) - is there a mechinism to test this?
>
> >
> >
> > I'm not sure what they need - if someone could check out the log and let me
> > know, I'll be happy to adjust them.
>
> cfk.gt.v3-Linux2.6.7-bk20-i810 and cfk.mdk.v3-Linux2.6.3 has old freetype.
> Same problem as with nearly every os.
So how do I get new freetype?
From alexander.gottwald at s1999.tu-chemnitz.de Thu Jul 29 06:05:00 2004
Date: Thu Jul 29 06:31:04 2004
In-Reply-To: <165901c47559$547f3b20$1e01a8c0@cnt496>
<165901c47559$547f3b20$1e01a8c0@cnt496>
On Thu, 29 Jul 2004, Carl Karsten wrote:
> > cfk.gt.v3-Linux2.6.7-bk20-i810 and cfk.mdk.v3-Linux2.6.3 has old freetype.
> > Same problem as with nearly every os.
>
> So how do I get new freetype?
For test compiling it is sufficient to add
#define HasFreetype2 NO
to config/cf/host.def. But I'dont know how you could tell tinderclient to creat
e
that file. I'd guess tinderclient has some way of running scripts right before t
he
compile starts.
Someone there who knows that for sure?
bye
ago
--
From elanthis at awesomeplay.com Thu Jul 29 07:10:07 2004
Date: Thu Jul 29 07:10:14 2004
In-Reply-To: <E1Bq7uE-0001Nl-00@mailgate.rz.uni-karlsruhe.de>
References: <E1Bq7uE-0001Nl-00@mailgate.rz.uni-karlsruhe.de>
On Thu, 2004-07-29 at 06:14, Amir Bukhari wrote:
> I noticed that both X implementations uses this mailing list. What the
> differences between them. Is Xserver the feature X Implementation for Xorg?
There is no software called XServer. The XServer CVS/project hosts
experimental code. It hosts the KDrive based X server, for example.
That software is *not* for end-users; it's for developers, testers, and
experimenters.
The Debrix project hosts the X server component of Xorg, if you are
looking for a stable X server that's pulled out of the monolithic X
build.
> We know NVIDIA Co has a kernel frame buffer for Linux, could we use it with
> Xfbdev with Xserver(not Xorg)?
>
> Amir Bukhari
> E-Mail: ufz6@rz.uni-karlsruhe.de
>
> _______________________________________________
> xorg mailing list
--
From jens at tungstengraphics.com Thu Jul 29 07:20:33 2004
From: jens at tungstengraphics.com (Jens Owen)
Date: Thu Jul 29 07:18:37 2004
In-Reply-To: <41087111.3000402@tungstengraphics.com>
<41087111.3000402@tungstengraphics.com>
Message-ID: <410907B1.2040109@tungstengraphics.com>
Brian Paul wrote:
> Jon Smirl wrote:
>
>> Slashdot is saying that SGI is going to port their clustered ATI
>> graphics to Linux in the near future. The SGI page says this code is
>> based on Chromium. I've read that the network protocol of Chromium is
>> far better than the GLX protocol, especially in the area of state
>> management. Does anyone have experience with both protocols and can
>> comment on how they compare?
>
>
> Sure...
>
>> If the Chromium protocol really is a lot better would it make sense to
>> evaluate shifting our focus from GLX to the Chromium protocol? In the
>> long run the coming shift to things like X on GL and Glitz may
>> ultimately move a lot of network traffic from the X protocol to one of
>> the GL ones. If Chromium is significantly better wouldn't it be wiser
>> to change the X server GL protocol now rather than later?
>
>
> The Chromium command packer packs GL commands more densely than GLX. A
> one-byte opcode is used for most commands and operands are packed
> tightly in memory. Opcodes are packed separate from the operands in a
> unique way too.
>
> Chromium also has a state tracking system which can eliminate redundant
> commands from being packed/sent. It's pretty complicated though and
> still a source of bugs.
>
> I wouldn't say that Chromium's packer is a *lot* better than GLX. And I
> wouldn't advocate switching to it. GLX interoperability is important
> and making such a switch would upset that. I don't think the effort to
> switch would be worth the trouble. Performance-wise, I think the gains
> would be quite modest.
Brian,
How about supporting key pieces of Chromium in the X.org release in
addition to GLX? Could integrating OpenGL API redirection, for example,
make for a cleaner solution than what Chromium does with "app faker" today?
--
/\
Jens Owen / \/\ _
jens@tungstengraphics.com / \ \ \ Steamboat Springs, Colorado
Date: Thu Jul 29 07:45:48 2004
<165901c47559$547f3b20$1e01a8c0@cnt496>
Message-ID: <41090E02.7090307@sun.com>
> On Thu, 29 Jul 2004, Carl Karsten wrote:
>
>
>>>cfk.gt.v3-Linux2.6.7-bk20-i810 and cfk.mdk.v3-Linux2.6.3 has old freetype.
>>>Same problem as with nearly every os.
>>
>>So how do I get new freetype?
>
>
> For test compiling it is sufficient to add
> #define HasFreetype2 NO
> to config/cf/host.def. But I'dont know how you could tell tinderclient to cre
ate
> that file. I'd guess tinderclient has some way of running scripts right before
the
> compile starts.
>
> Someone there who knows that for sure?
>
> bye
> ago
TinderClientModules/XMonolithic.pm has examples of adding settings to host.def
Copy one of those and modify as necessary (changing "if (0)" to "if (1)" of cour
se)
--
From Jim.Gettys at hp.com Thu Jul 29 07:50:11 2004
Date: Thu Jul 29 07:50:18 2004
References: <E1Bq7uE-0001Nl-00@mailgate.rz.uni-karlsruhe.de>
On Thu, 2004-07-29 at 10:10, Sean Middleditch wrote:
> On Thu, 2004-07-29 at 06:14, Amir Bukhari wrote:
> > I noticed that both X implementations uses this mailing list. What the
> > differences between them. Is Xserver the feature X Implementation for Xorg?
>
> There is no software called XServer. The XServer CVS/project hosts
> experimental code. It hosts the KDrive based X server, for example.
> That software is *not* for end-users; it's for developers, testers, and
> experimenters.
>
One nit: those using embedded devices use kdrive based servers
typically; certainly developers of such devices are interested
in these bits, even if they are not developers of X itself.
Hopefully we'll get all this pulled back together again over
the next 6 months or so...
- Jim
Date: Thu Jul 29 08:07:28 2004
In-Reply-To: <410907B1.2040109@tungstengraphics.com>
<410907B1.2040109@tungstengraphics.com>
Message-ID: <Pine.LNX.4.56.0407291805030.1757@typhoon-05.cs.huji.ac.il>
isn't it based on wiregl?
which supports distributed rendering and is preety much faster than
indirect glx?
I don't remember how it worked?it changed libGL no? which works above
glx, so it does use glx for direct rendering on the computer you are on.
so it doesn't need to really replace glx only be on top of it?
or am I wrong?
Anyhow it would probebly be more intresting to look into when
The opengl based Xserver would advacne?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Thu, 29 Jul 2004, Jens Owen wrote:
> Brian Paul wrote:
> >
> >> Slashdot is saying that SGI is going to port their clustered ATI
> >> graphics to Linux in the near future. The SGI page says this code is
> >> based on Chromium. I've read that the network protocol of Chromium is
> >> far better than the GLX protocol, especially in the area of state
> >> management. Does anyone have experience with both protocols and can
> >> comment on how they compare?
> >
> >
> > Sure...
> >
> >> If the Chromium protocol really is a lot better would it make sense to
> >> evaluate shifting our focus from GLX to the Chromium protocol? In the
> >> long run the coming shift to things like X on GL and Glitz may
> >> ultimately move a lot of network traffic from the X protocol to one of
> >> the GL ones. If Chromium is significantly better wouldn't it be wiser
> >> to change the X server GL protocol now rather than later?
> >
> >
> > The Chromium command packer packs GL commands more densely than GLX. A
> > one-byte opcode is used for most commands and operands are packed
> > tightly in memory. Opcodes are packed separate from the operands in a
> > unique way too.
> >
> > Chromium also has a state tracking system which can eliminate redundant
> > commands from being packed/sent. It's pretty complicated though and
> > still a source of bugs.
> >
> > I wouldn't say that Chromium's packer is a *lot* better than GLX. And I
> > wouldn't advocate switching to it. GLX interoperability is important
> > and making such a switch would upset that. I don't think the effort to
> > switch would be worth the trouble. Performance-wise, I think the gains
> > would be quite modest.
>
> Brian,
>
> How about supporting key pieces of Chromium in the X.org release in
> addition to GLX? Could integrating OpenGL API redirection, for example,
> make for a cleaner solution than what Chromium does with "app faker" today?
>
> --
> /\
> Jens Owen / \/\ _
> jens@tungstengraphics.com / \ \ \ Steamboat Springs, Colorado
>
> _______________________________________________
> xorg mailing list
>
Date: Thu Jul 29 08:20:28 2004
Subject: [Xorg] Update on video memory manager work
In-Reply-To: <4108447B.6020001@us.ibm.com>
References: <4108447B.6020001@us.ibm.com>
On Iau, 2004-07-29 at 01:27, Ian Romanick wrote:
> So, I'm going to rework the interface a little bit so that the allocator
> can look at all the require allocations at once. It will place them in
> memory using some sort of path finding algorithm (probably A*). That
> seems like a reasonably good fit. Who thought you'd need AI for a video
> driver? ;)
Cool stuff. The sis6326 needs this ability for a much more primitive
reason - because a texture cannot have some levels in framebuffer and
some in AGP.
Date: Thu Jul 29 08:24:00 2004
In-Reply-To: <410907B1.2040109@tungstengraphics.com>
Message-ID: <a728f9f9040729081742ab0fd@mail.gmail.com>
On Thu, 29 Jul 2004 08:20:33 -0600, Jens Owen <jens@tungstengraphics.com> wrote:
> Brian Paul wrote:
> >
> >> Slashdot is saying that SGI is going to port their clustered ATI
> >> graphics to Linux in the near future. The SGI page says this code is
> >> based on Chromium. I've read that the network protocol of Chromium is
> >> far better than the GLX protocol, especially in the area of state
> >> management. Does anyone have experience with both protocols and can
> >> comment on how they compare?
> >
> >
> > Sure...
> >
> >> If the Chromium protocol really is a lot better would it make sense to
> >> evaluate shifting our focus from GLX to the Chromium protocol? In the
> >> long run the coming shift to things like X on GL and Glitz may
> >> ultimately move a lot of network traffic from the X protocol to one of
> >> the GL ones. If Chromium is significantly better wouldn't it be wiser
> >> to change the X server GL protocol now rather than later?
> >
> >
> > The Chromium command packer packs GL commands more densely than GLX. A
> > one-byte opcode is used for most commands and operands are packed
> > tightly in memory. Opcodes are packed separate from the operands in a
> > unique way too.
> >
> > Chromium also has a state tracking system which can eliminate redundant
> > commands from being packed/sent. It's pretty complicated though and
> > still a source of bugs.
> >
> > I wouldn't say that Chromium's packer is a *lot* better than GLX. And I
> > wouldn't advocate switching to it. GLX interoperability is important
> > and making such a switch would upset that. I don't think the effort to
> > switch would be worth the trouble. Performance-wise, I think the gains
> > would be quite modest.
>
> Brian,
>
> How about supporting key pieces of Chromium in the X.org release in
> addition to GLX? Could integrating OpenGL API redirection, for example,
> make for a cleaner solution than what Chromium does with "app faker" today?
couldn't chromium be merged into xorg someday to provide multi-head
open GL in conjunction with dmx on the same box or different boxes?
Say you have two 3d cards each could be brought up as independant X
servers with their own instances of the DRI. Then chromium and DMX
could provide the middle layer so that multi-card hw Open GL would
just work for a xinerama desktop.
Alex
>
> --
> /\
> Jens Owen / \/\ _
> jens@tungstengraphics.com / \ \ \ Steamboat Springs, Colorado
>
> _______________________________________________
> xorg mailing list
>
Date: Thu Jul 29 09:12:49 2004
In-Reply-To: <a728f9f9040729081742ab0fd@mail.gmail.com>
<a728f9f9040729081742ab0fd@mail.gmail.com>
Hash: SHA1
On Thursday 29 July 2004 11:17, Alex Deucher wrote:
> couldn't chromium be merged into xorg someday to provide multi-head
> open GL in conjunction with dmx on the same box or different boxes?
> Say you have two 3d cards each could be brought up as independant X
> servers with their own instances of the DRI. Then chromium and DMX
> could provide the middle layer so that multi-card hw Open GL would
> just work for a xinerama desktop.
Heh. It won't be hardware-accelerated until we ditch GLcore for *_dri.so in
the server. DMX just uses whatever indirect rendering path the server
provides. There's a reason this is on my todo list ;)
- - ajax
iD8DBQFBCSBqW4otUKDs0NMRAplMAKCrzq3xYx979pxapXoHKYaXG5kSyACgptJ3
ow9KmZXrUpN0o9Jx1YXGWP8=
=FQoA
Date: Thu Jul 29 09:36:27 2004
Subject: [Xorg] Debrix troubles on Linux/ppc
[Sorry, I should have sent this to the list in the first place. Private
e-mail exchanges prevent the growth of community knowledge and make public
archives less useful.]
I updated my debrix and debrix-driver-ati trees today in the hopes that this
would be magically fixed, but it's not. I can keep hacking around if you
don't have any quick ideas about why this might be happening, otherwise I'd
be happy to try whatever you suggest.
When I use the ati driver (specified in my xorg.conf file), it seems that the
driver starts up but doesn't want to talk to my card.
When I try the fbdev driver, the X server seems to start and run ok, but I get
no output on the screen.
Thanks,
Jesse
I run it with:
$ Xorg -xf86config xorg.conf -logfile xorg.out -verbose 9
PCI:
$ lspci
0000:00:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 AGP
0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility
Radeon 9600 M10]
0001:01:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 PCI
0001:01:12.0 Network controller: Broadcom Corporation BCM4306 802.11b/g
Wireless LAN Controller (rev 03)
0001:01:13.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus
Controller
0001:01:17.0 ff00: Apple Computer Inc. KeyLargo/Intrepid Mac I/O
0001:01:18.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0001:01:19.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0001:01:1a.0 USB Controller: Apple Computer Inc. KeyLargo/Intrepid USB
0001:01:1b.0 USB Controller: NEC Corporation USB (rev 43)
0001:01:1b.1 USB Controller: NEC Corporation USB (rev 43)
0001:01:1b.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
0002:06:0b.0 Host bridge: Apple Computer Inc. UniNorth 2 Internal PCI
0002:06:0d.0 ff00: Apple Computer Inc. UniNorth/Intrepid ATA/100
0002:06:0e.0 FireWire (IEEE 1394): Apple Computer Inc. UniNorth 2 FireWire
(rev 81)
0002:06:0f.0 Ethernet controller: Apple Computer Inc. UniNorth 2 GMAC (Sun
GEM) (rev 80)
-------------- next part --------------
This is a pre-release version of the freedesktop.org X11.
Portions of this release are based on XFree86 4.4RC2 and selected
files from XFree86 4.4RC3. It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the freedesktop.org "monolithic tree" CVS
repository hosted at http://www.freedesktop.org/Software/xorg/.902
X Protocol Version 11, Revision 0, 6.7.1
Build Operating System: unknown
Current Operating System: Linux mill.virtuousgeek.org 2.6.7 #4 Wed Jun 23 08:09:
35 EDT 2004 ppc
Before reporting problems, check http://wiki.x.org
(++) Log file: "xorg.out", Time: Wed Jul 28 17:59:06 2004
(++) Using config file: "xorg.conf"
(WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist.
Entry deleted from font path.
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Sp
eedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6
/lib/X11/fonts/100dpi/"
dlloader: main binary loaded.
full io access
busprobe
xf86SetupPciIds: 268976096
(II) PCI: 00:0b:0: chip 6b10,3400 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:10:0: chip 0210,504e card 0210,504e rev 00 class 03,00,00 hdr 00
(II) PCI: 01:12:0: chip e414,2043 card 6b10,4e00 rev 03 class 02,80,00 hdr 00
(II) PCI: 01:13:0: chip 4c10,56ac card 0010,0000 rev 00 class 06,07,00 hdr 02
(II) PCI: 01:17:0: chip 6b10,3e00 card 0000,0000 rev 00 class ff,00,00 hdr 00
(II) PCI: 01:18:0: chip 6b10,3f00 card 0000,0000 rev 00 class 0c,03,10 hdr 00
(II) PCI: 01:1a:0: chip 6b10,3f00 card 0000,0000 rev 00 class 0c,03,10 hdr 00
(II) PCI: 01:1b:0: chip 3310,3500 card 3310,3500 rev 43 class 0c,03,10 hdr 80
(II) PCI: 01:1b:2: chip 3310,e000 card 3310,e000 rev 04 class 0c,03,20 hdr 00
(II) PCI: 06:0d:0: chip 6b10,3b00 card 0000,0000 rev 00 class ff,00,00 hdr 00
(II) PCI: 06:0e:0: chip 6b10,3100 card 6b10,1158 rev 81 class 0c,00,10 hdr 00
(II) PCI: 06:0f:0: chip 6b10,3200 card 0000,0000 rev 80 class 02,00,00 hdr 00
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-CardBus bridge:
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(--) PCI: (0:16:0) unknown vendor (0x0210) unknown chipset (0x504e) rev 0, Mem @
0x080000b0/27, 0x01040000/8, 0x000000b0/16, BIOS @ 0x01000000/17
doprobe
doconfigure
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[0] -1 0 0x000000a0 - 0x0000019f (0x100) MX[B]
[1] -1 0 0x001000a0 - 0x0010109f (0x1000) MX[B]
[2] -1 0 0x002000a0 - 0x0020109f (0x1000) MX[B]
[3] -1 0 0x003000a0 - 0x0030109f (0x1000) MX[B]
[4] -1 0 0x00000080 - 0x0008007f (0x80000) MX[B]
[5] -1 0 0x006000a0 - 0x0060209f (0x2000) MX[B]
[6] -1 0 0x01000000 - 0x0101ffff (0x20000) MX[B](B)
[7] -1 0 0x000000b0 - 0x000100af (0x10000) MX[B](B)
[8] -1 0 0x01040000 - 0x010400ff (0x100) MX[B](B)
[9] -1 0 0x080000b0 - 0x100000af (0x8000000) MX[B](B)
[10] -1 0 0x000020f4 - 0x002020f3 (0x200000) IX[B]
[11] -1 0 0x000000f4 - 0x000010f3 (0x1000) IX[B]
[12] -1 0 0x004000f4 - 0x004040f3 (0x4000) IX[B]
[13] -1 0 0x001000f0 - 0x001010ef (0x1000) IX[B]
[14] -1 0 0x000000f0 - 0x000010ef (0x1000) IX[B]
[0] -1 0 0x000000a0 - 0x0000019f (0x100) MX[B]
[1] -1 0 0x001000a0 - 0x0010109f (0x1000) MX[B]
[2] -1 0 0x002000a0 - 0x0020109f (0x1000) MX[B]
[3] -1 0 0x003000a0 - 0x0030109f (0x1000) MX[B]
[4] -1 0 0x00000080 - 0x0008007f (0x80000) MX[B]
[5] -1 0 0x006000a0 - 0x0060209f (0x2000) MX[B]
[6] -1 0 0x01000000 - 0x0101ffff (0x20000) MX[B](B)
[7] -1 0 0x000000b0 - 0x000100af (0x10000) MX[B](B)
[8] -1 0 0x01040000 - 0x010400ff (0x100) MX[B](B)
[9] -1 0 0x080000b0 - 0x100000af (0x8000000) MX[B](B)
[10] -1 0 0x000020f4 - 0x002020f3 (0x200000) IX[B]
[11] -1 0 0x000000f4 - 0x000010f3 (0x1000) IX[B]
[12] -1 0 0x004000f4 - 0x004040f3 (0x4000) IX[B]
[13] -1 0 0x001000f0 - 0x001010ef (0x1000) IX[B]
[14] -1 0 0x000000f0 - 0x000010ef (0x1000) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x000000a0 - 0x0000019f (0x100) MX[B]
[6] -1 0 0x001000a0 - 0x0010109f (0x1000) MX[B]
[7] -1 0 0x002000a0 - 0x0020109f (0x1000) MX[B]
[8] -1 0 0x003000a0 - 0x0030109f (0x1000) MX[B]
[9] -1 0 0x00000080 - 0x0008007f (0x80000) MX[B]
[10] -1 0 0x006000a0 - 0x0060209f (0x2000) MX[B]
[11] -1 0 0x01000000 - 0x0101ffff (0x20000) MX[B](B)
[12] -1 0 0x000000b0 - 0x000100af (0x10000) MX[B](B)
[13] -1 0 0x01040000 - 0x010400ff (0x100) MX[B](B)
[14] -1 0 0x080000b0 - 0x100000af (0x8000000) MX[B](B)
[15] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[16] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[17] -1 0 0x000020f4 - 0x002020f3 (0x200000) IX[B]
[18] -1 0 0x000000f4 - 0x000010f3 (0x1000) IX[B]
[19] -1 0 0x004000f4 - 0x004040f3 (0x4000) IX[B]
[20] -1 0 0x001000f0 - 0x001010ef (0x1000) IX[B]
[21] -1 0 0x000000f0 - 0x000010ef (0x1000) IX[B]
(II) LoadModule: "ati"
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="The XFree86 Project"
compiled for 4.3.0.1, module version = 6.5.5
Module class: XFree86 Video Driver
ABI class: XFree86 Video Driver, version 0.6
(II) Module mouse: vendor="The XFree86 Project"
Module class: XFree86 XInput Driver
ABI class: XFree86 XInput driver, version 0.4
(II) ATI: ATI driver (version 6.5.5) for chipset: ati
(II) R128: Driver for ATI Rage 128 chipsets:
ATI Rage 128 Mobility M3 LE (PCI), ATI Rage 128 Mobility M3 LF (AGP),
ATI Rage 128 Mobility M4 MF (AGP), ATI Rage 128 Mobility M4 ML (AGP),
ATI Rage 128 Pro GL PA (AGP?), ATI Rage 128 Pro GL PB (AGP?),
ATI Rage 128 Pro GL PC (AGP?), ATI Rage 128 Pro GL PD (PCI),
ATI Rage 128 Pro GL PE (AGP?), ATI Rage 128 Pro GL PF (AGP),
ATI Rage 128 Pro VR PG (AGP?), ATI Rage 128 Pro VR PH (AGP?),
ATI Rage 128 Pro VR PI (AGP?), ATI Rage 128 Pro VR PJ (AGP?),
ATI Rage 128 Pro VR PK (AGP?), ATI Rage 128 Pro VR PL (AGP?),
ATI Rage 128 Pro VR PM (AGP?), ATI Rage 128 Pro VR PN (AGP?),
ATI Rage 128 Pro VR PO (AGP?), ATI Rage 128 Pro VR PP (PCI),
ATI Rage 128 Pro VR PQ (AGP?), ATI Rage 128 Pro VR PR (PCI),
ATI Rage 128 Pro VR PS (AGP?), ATI Rage 128 Pro VR PT (AGP?),
ATI Rage 128 Pro VR PU (AGP?), ATI Rage 128 Pro VR PV (AGP?),
ATI Rage 128 Pro VR PW (AGP?), ATI Rage 128 Pro VR PX (AGP?),
ATI Rage 128 GL RE (PCI), ATI Rage 128 GL RF (AGP),
ATI Rage 128 RG (AGP), ATI Rage 128 VR RK (PCI),
ATI Rage 128 VR RL (AGP), ATI Rage 128 4X SE (AGP?),
ATI Rage 128 4X SF (AGP?), ATI Rage 128 4X SG (AGP?),
ATI Rage 128 4X SH (AGP?), ATI Rage 128 4X SK (AGP?),
ATI Rage 128 4X SL (AGP?), ATI Rage 128 4X SM (AGP),
ATI Rage 128 4X SN (AGP?), ATI Rage 128 Pro ULTRA TF (AGP),
ATI Rage 128 Pro ULTRA TL (AGP), ATI Rage 128 Pro ULTRA TR (AGP),
ATI Rage 128 Pro ULTRA TS (AGP?), ATI Rage 128 Pro ULTRA TT (AGP?),
ATI Rage 128 Pro ULTRA TU (AGP?)
(II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon QD (AGP),
ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP),
ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI),
ATI Radeon Mobility M7 LW (AGP),
ATI Mobility FireGL 7800 M7 LX (AGP),
ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP),
ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP320M (U1) 4336,
ATI Radeon IGP330/340/350 (A4) 4137,
ATI Radeon IGP330M/340M/350M (U2) 4337,
ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon Mobility 7000 IGP 4437,
ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP),
ATI Radeon 9100 QM (AGP), ATI Radeon 8500 AIW BB (AGP),
ATI Radeon 8500 AIW BC (AGP), ATI Radeon 7500 QW (AGP/PCI),
ATI Radeon 7500 QX (AGP/PCI), ATI Radeon 9000/PRO If (AGP/PCI),
ATI Radeon 9000 Ig (AGP/PCI), ATI FireGL Mobility 9000 (M9) Ld (AGP),
ATI Radeon Mobility 9000 (M9) Lf (AGP),
ATI Radeon Mobility 9000 (M9) Lg (AGP),
ATI Radeon 9100 IGP (A5) 5834,
ATI Radeon Mobility 9100 IGP (U3) 5835,
ATI Radeon 9200PRO 5960 (AGP), ATI Radeon 9200 5961 (AGP),
ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C61 (AGP),
ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Radeon 9500 AD (AGP),
ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP),
ATI FireGL Z1 AG (AGP), ATI Radeon 9700 Pro ND (AGP),
ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9700 NF (AGP),
ATI FireGL X1 NG (AGP), ATI Radeon 9600 AP (AGP),
ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP),
ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP),
ATI FireGL RV360 AV (AGP), ATI Radeon Mobility 9600 (M10) NP (AGP),
ATI Radeon Mobility 9600 (M10) NQ (AGP),
ATI Radeon Mobility 9600 (M11) NR (AGP),
ATI Radeon Mobility 9600 (M10) NS (AGP),
ATI FireGL Mobility T2 (M10) NT (AGP),
ATI FireGL Mobility T2 (M11) NV (AGP), ATI Radeon 9800SE AH (AGP),
ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP),
ATI FireGL X2 AK (AGP), ATI Radeon 9800PRO NH (AGP),
ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP),
ATI Radeon 9800XT NJ (AGP)
(II) ATI: Candidate "Device" section "Card0".
(EE) No devices detected.
Fatal server error:
no screens found
-------------- next part --------------
This is a pre-release version of the freedesktop.org X11.
Portions of this release are based on XFree86 4.4RC2 and selected
files from XFree86 4.4RC3. It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the freedesktop.org "monolithic tree" CVS
repository hosted at http://www.freedesktop.org/Software/xorg/.902
X Protocol Version 11, Revision 0, 6.7.1
Build Operating System: unknown
Current Operating System: Linux mill.virtuousgeek.org 2.6.7 #4 Wed Jun 23 08:09:
35 EDT 2004 ppc
Before reporting problems, check http://wiki.x.org
(++) Log file: "xorg.out", Time: Wed Jul 28 17:57:32 2004
(++) Using config file: "xorg.conf"
(WW) The directory "/usr/X11R6/lib/X11/fonts/CID/" does not exist.
Entry deleted from font path.
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Sp
eedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6
/lib/X11/fonts/100dpi/"
dlloader: main binary loaded.
full io access
busprobe
xf86SetupPciIds: 268976096
(II) PCI: 00:10:0: chip 0210,504e card 0210,504e rev 00 class 03,00,00 hdr 00
(II) PCI: 01:12:0: chip e414,2043 card 6b10,4e00 rev 03 class 02,80,00 hdr 00
(II) PCI: 01:13:0: chip 4c10,56ac card 0010,0000 rev 00 class 06,07,00 hdr 02
(II) PCI: 01:17:0: chip 6b10,3e00 card 0000,0000 rev 00 class ff,00,00 hdr 00
(II) PCI: 01:1a:0: chip 6b10,3f00 card 0000,0000 rev 00 class 0c,03,10 hdr 00
(II) PCI: 01:1b:2: chip 3310,e000 card 3310,e000 rev 04 class 0c,03,20 hdr 00
(II) PCI: 06:0d:0: chip 6b10,3b00 card 0000,0000 rev 00 class ff,00,00 hdr 00
(II) PCI: 06:0e:0: chip 6b10,3100 card 6b10,1158 rev 81 class 0c,00,10 hdr 00
(II) PCI: 06:0f:0: chip 6b10,3200 card 0000,0000 rev 80 class 02,00,00 hdr 00
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) PCI-to-CardBus bridge:
[0] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(--) PCI: (0:16:0) unknown vendor (0x0210) unknown chipset (0x504e) rev 0, Mem @
0x080000b0/27, 0x01040000/8, 0x000000b0/16, BIOS @ 0x01000000/17
doprobe
doconfigure
[0] -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[0] -1 0 0x000000a0 - 0x0000019f (0x100) MX[B]
[1] -1 0 0x001000a0 - 0x0010109f (0x1000) MX[B]
[2] -1 0 0x002000a0 - 0x0020109f (0x1000) MX[B]
[3] -1 0 0x003000a0 - 0x0030109f (0x1000) MX[B]
[4] -1 0 0x00000080 - 0x0008007f (0x80000) MX[B]
[5] -1 0 0x006000a0 - 0x0060209f (0x2000) MX[B]
[6] -1 0 0x01000000 - 0x0101ffff (0x20000) MX[B](B)
[7] -1 0 0x000000b0 - 0x000100af (0x10000) MX[B](B)
[8] -1 0 0x01040000 - 0x010400ff (0x100) MX[B](B)
[9] -1 0 0x080000b0 - 0x100000af (0x8000000) MX[B](B)
[10] -1 0 0x000020f4 - 0x002020f3 (0x200000) IX[B]
[11] -1 0 0x000000f4 - 0x000010f3 (0x1000) IX[B]
[12] -1 0 0x004000f4 - 0x004040f3 (0x4000) IX[B]
[13] -1 0 0x001000f0 - 0x001010ef (0x1000) IX[B]
[14] -1 0 0x000000f0 - 0x000010ef (0x1000) IX[B]
[0] -1 0 0x000000a0 - 0x0000019f (0x100) MX[B]
[1] -1 0 0x001000a0 - 0x0010109f (0x1000) MX[B]
[2] -1 0 0x002000a0 - 0x0020109f (0x1000) MX[B]
[3] -1 0 0x003000a0 - 0x0030109f (0x1000) MX[B]
[4] -1 0 0x00000080 - 0x0008007f (0x80000) MX[B]
[5] -1 0 0x006000a0 - 0x0060209f (0x2000) MX[B]
[6] -1 0 0x01000000 - 0x0101ffff (0x20000) MX[B](B)
[7] -1 0 0x000000b0 - 0x000100af (0x10000) MX[B](B)
[8] -1 0 0x01040000 - 0x010400ff (0x100) MX[B](B)
[9] -1 0 0x080000b0 - 0x100000af (0x8000000) MX[B](B)
[10] -1 0 0x000020f4 - 0x002020f3 (0x200000) IX[B]
[11] -1 0 0x000000f4 - 0x000010f3 (0x1000) IX[B]
[12] -1 0 0x004000f4 - 0x004040f3 (0x4000) IX[B]
[13] -1 0 0x001000f0 - 0x001010ef (0x1000) IX[B]
[14] -1 0 0x000000f0 - 0x000010ef (0x1000) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[6] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[2] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[3] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[4] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[5] -1 0 0x000000a0 - 0x0000019f (0x100) MX[B]
[6] -1 0 0x001000a0 - 0x0010109f (0x1000) MX[B]
[7] -1 0 0x002000a0 - 0x0020109f (0x1000) MX[B]
[8] -1 0 0x003000a0 - 0x0030109f (0x1000) MX[B]
[9] -1 0 0x00000080 - 0x0008007f (0x80000) MX[B]
[10] -1 0 0x006000a0 - 0x0060209f (0x2000) MX[B]
[11] -1 0 0x01000000 - 0x0101ffff (0x20000) MX[B](B)
[12] -1 0 0x000000b0 - 0x000100af (0x10000) MX[B](B)
[13] -1 0 0x01040000 - 0x010400ff (0x100) MX[B](B)
[14] -1 0 0x080000b0 - 0x100000af (0x8000000) MX[B](B)
[15] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[16] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[17] -1 0 0x000020f4 - 0x002020f3 (0x200000) IX[B]
[18] -1 0 0x000000f4 - 0x000010f3 (0x1000) IX[B]
[19] -1 0 0x004000f4 - 0x004040f3 (0x4000) IX[B]
[20] -1 0 0x001000f0 - 0x001010ef (0x1000) IX[B]
[21] -1 0 0x000000f0 - 0x000010ef (0x1000) IX[B]
(II) LoadModule: "fbdev"
(II) Loading /usr/X11R6/lib/modules/drivers/fbdev_drv.o
(II) Module fbdev: vendor="The XFree86 Project"
ABI class: XFree86 Video Driver, version 0.6
(II) Module mouse: vendor="The XFree86 Project"
Module class: XFree86 XInput Driver
ABI class: XFree86 XInput driver, version 0.4
(II) FBDEV: driver for framebuffer: fbdev, afb
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading fbdevhw
(II) Module fbdevhw: vendor="X.Org Foundation"
Date: Thu Jul 29 09:39:49 2004
<200407291206.03512.ajax@nwnk.net>
Message-ID: <a728f9f90407290939745713b2@mail.gmail.com>
On Thu, 29 Jul 2004 12:05:59 -0400, Adam Jackson <ajax@nwnk.net> wrote:
> Hash: SHA1
>
> On Thursday 29 July 2004 11:17, Alex Deucher wrote:
> > couldn't chromium be merged into xorg someday to provide multi-head
> > open GL in conjunction with dmx on the same box or different boxes?
> > Say you have two 3d cards each could be brought up as independant X
> > servers with their own instances of the DRI. Then chromium and DMX
> > could provide the middle layer so that multi-card hw Open GL would
> > just work for a xinerama desktop.
>
> Heh. It won't be hardware-accelerated until we ditch GLcore for *_dri.so in
> the server. DMX just uses whatever indirect rendering path the server
> provides. There's a reason this is on my todo list ;)
That's glxproxy. dmx plus chromium can use direct rendering as I recall.
Alex
>
> - - ajax
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBCSBqW4otUKDs0NMRAplMAKCrzq3xYx979pxapXoHKYaXG5kSyACgptJ3
> ow9KmZXrUpN0o9Jx1YXGWP8=
> =FQoA
> -----END PGP SIGNATURE-----
>
From keith at tungstengraphics.com Thu Jul 29 09:15:39 2004
Date: Thu Jul 29 09:45:28 2004
References: <20040729004144.92945.qmail@web14930.mail.yahoo.com> <410907B
1.2040109@tungstengraphics.com> <a728f9f9040729081742ab0fd@mail.gmail.com>
<200407291206.03512.ajax@nwnk.net>
Message-ID: <410922AB.1070302@tungstengraphics.com>
Adam Jackson wrote:
> Hash: SHA1
>
>
>>couldn't chromium be merged into xorg someday to provide multi-head
>>open GL in conjunction with dmx on the same box or different boxes?
>>Say you have two 3d cards each could be brought up as independant X
>>servers with their own instances of the DRI. Then chromium and DMX
>>could provide the middle layer so that multi-card hw Open GL would
>>just work for a xinerama desktop.
>
>
> Heh. It won't be hardware-accelerated until we ditch GLcore for *_dri.so in
> the server. DMX just uses whatever indirect rendering path the server
> provides. There's a reason this is on my todo list ;)
Chromium provides accelerated rendering over the network, but the current
interfaces are designed to support all manner of complex setups and don't have
the convenience of things like "DISPLAY=thathost:0 glxgears".
Keith
Date: Thu Jul 29 10:17:42 2004
In-Reply-To: <410922AB.1070302@tungstengraphics.com>
<200407291206.03512.ajax@nwnk.net>
<410922AB.1070302@tungstengraphics.com>
Message-ID: <Pine.LNX.4.56.0407292009500.2132@typhoon-05.cs.huji.ac.il>
Hey,
It seems that even if we would gain anything from it, it would require
adjusting and some work,
Probebly more than a bit to fit the way Xorg people see things,
Are the people from Chromium even intrested in it?
Would they gain anything from helping Xorg support instead of glx?
Is there someone around who knows both glx/Chromium well enough to answer
xorg's people questions and concerns?
Like what would it gain in the fields of features and speed (both regular
and DMX/distributed like things)?
Would it allow new features?
Would it make things less complicated?How does it work with mesagl?
Ely Levy
System group
Hebrew University
Jerusalem Israel
Date: Thu Jul 29 10:29:09 2004
<200407291206.03512.ajax@nwnk.net>
Hash: SHA1
On Thursday 29 July 2004 12:39, Alex Deucher wrote:
> On Thu, 29 Jul 2004 12:05:59 -0400, Adam Jackson <ajax@nwnk.net> wrote:
> > Heh. It won't be hardware-accelerated until we ditch GLcore for *_dri.so
> > in the server. DMX just uses whatever indirect rendering path the server
> > provides. There's a reason this is on my todo list ;)
>
> That's glxproxy. dmx plus chromium can use direct rendering as I recall.
As I understand it, Chromium redirects all the GL protocol among their own
processes, which then act as normal X clients and can therefore do direct
rendering. This is not the model I had in mind; I'd much prefer to see
accelerated indirect rendering, because then I can just point Xdmx :2 at my
two DRI-capable X servers and treat the Xdmx as my only X server, no matter
what, no funky libGL redirection tricks, no extra client/server pairs to set
up.
It might then be interesting to teach the X server to speak the Chromium
protocol. But if we're aiming for accelerated indirect rendering, and our
options are Chromium or replacing GLcore, then I for one want to see GLcore
dead and buried. That way we give accelerated indirect rendering to every
GLX client on the planet with no additional software on the client side.
Particularly if, as Brian says, the performance gain from switching from the
GLX to Chromium protocols is "quite modest".
- - ajax
iD8DBQFBCTJOW4otUKDs0NMRAokzAKCavvWo3WbKfr6hFpCdPJVHSS3+iQCfVfx9
0KNmWh7SzggMZJkrqsQ7n6g=
=913v
Date: Thu Jul 29 11:33:42 2004
<200407291206.03512.ajax@nwnk.net>
<200407291322.24293.ajax@nwnk.net>
Message-ID: <a728f9f90407291133676a2e7@mail.gmail.com>
On Thu, 29 Jul 2004 13:22:22 -0400, Adam Jackson <ajax@nwnk.net> wrote:
> Hash: SHA1
>
> > On Thu, 29 Jul 2004 12:05:59 -0400, Adam Jackson <ajax@nwnk.net> wrote:
> > > Heh. It won't be hardware-accelerated until we ditch GLcore for *_dri.so
> > > in the server. DMX just uses whatever indirect rendering path the server
> > > provides. There's a reason this is on my todo list ;)
> >
> > That's glxproxy. dmx plus chromium can use direct rendering as I recall.
>
> As I understand it, Chromium redirects all the GL protocol among their own
> processes, which then act as normal X clients and can therefore do direct
> rendering. This is not the model I had in mind; I'd much prefer to see
> accelerated indirect rendering, because then I can just point Xdmx :2 at my
> two DRI-capable X servers and treat the Xdmx as my only X server, no matter
> what, no funky libGL redirection tricks, no extra client/server pairs to set
> up.
I agree with you 100%. I was just making a note of the difference.
>
> It might then be interesting to teach the X server to speak the Chromium
> protocol. But if we're aiming for accelerated indirect rendering, and our
> options are Chromium or replacing GLcore, then I for one want to see GLcore
> dead and buried. That way we give accelerated indirect rendering to every
> GLX client on the planet with no additional software on the client side.
> Particularly if, as Brian says, the performance gain from switching from the
> GLX to Chromium protocols is "quite modest".
>
> - - ajax
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBCTJOW4otUKDs0NMRAokzAKCavvWo3WbKfr6hFpCdPJVHSS3+iQCfVfx9
> 0KNmWh7SzggMZJkrqsQ7n6g=
> =913v
> -----END PGP SIGNATURE-----
>
Date: Thu Jul 29 12:48:28 2004
References: <10ca01c474d3$1f1fdd80$1e01a8c0@cnt496><Pine.LNX.4.58.0407282116240.
9508@odoaker.hrz.tu-chemnitz.de><165901c47559$547f3b20$1e01a8c0@cnt496><Pine.LNX
.4.58.0407291500510.9508@odoaker.hrz.tu-chemnitz.de>
<41090E02.7090307@sun.com>
Message-ID: <19d601c475a5$0128ef10$1e01a8c0@cnt496>
> TinderClientModules/XMonolithic.pm has examples of adding settings to host.def
> Copy one of those and modify as necessary (changing "if (0)" to "if (1)" of
course)
Got it, I think:
# Some common configuration options that are disabled by default.
$hostdef = $hostdef . "#define HasFreetype2 NO \n";
if (0) {
$hostdef = $hostdef . "#define BuildXF86DRI NO\n";
}
If the cfk boxes go past 1h 45 min, it worked.
Carl K
Date: Thu Jul 29 12:53:01 2004
Subject: [Xorg] OLS and console rearchitecture: second pass
I've sent this out to fbdev and dri already. I'm not getting very much
feedback so we may all be coming into agreement.
After talking to many people at OLS this seems to be the consensus for
rearchitecting fbdev/DRM. It has been proposed that this design be a
five year goal but there is still disagreement about the exact path to
get there.
This is a first pass for the fbdev/DRM people. I will incorporate
comments and repost to lkml for the final pass. I'm sure everyone will
let me know if I've misinterpreted some of the design points.
First a basic definition. There are two consoles, the kernel one
(printk, kdbg, OOPs, etc) and user one (normal console logins). In
Linux these are currently implemented with the same code. There may be
advantages to splitting the implementation in a future design.
1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
track the boot video device and expose the contents of C000:0 for that
special case.
2) VGA control - there needs to be a device for coordinating this. It
would ensure that only a single VGA device gets enabled at a time. It
would also adjust PCI bus routing as needed. It needs commands for
disabling all VGA devices and then enabling a selected one. This device
may need to coordinate with VGA console. You have to use this device
even if you aren't using VGA console since it ensures that only a
single VGA device gets enabled.
Alan Cox: what about hardware that supports multiple vga routers? do we
care?
3) Secondary card reset - Handled by an initial hotplug event. We need
a volunteer to write clean vm86 and emu86 apps for running the ROM
initialization. Resetting needs #1 and #2 to work since resetting a
card will enable it's VGA mode. I have an implementation of this but it
needs a lot of clean up.
4) DRM code reorganization. There were several requests to reorganize
DRM to more closely follow the Linux kernel guidelines. This
reorganization should occur before new features are added.
5) Multihead cards will expose one device file per head. Many IOCTLs
exposed by these devices will be common. Some, like mode setting, will
be per head.
6) Mode setting before early user space - this was decided to be a
platform specific problem. With minor adjustment the kernel can be made
to boot without printing anything except errors before early user space
starts. Platform specific code will need to handle these error messages
if any. This includes INT10, Openfirmware, mainframe serial consoles,
VGA mode. Suppressing informatory printing before early user space
starts allows a clean boot straight into graphics mode.
7) Mode setting from normal user space - devices will have a standard
IOCTL accepting a mode string like fbdev currently uses. This IOCTL
will lock the device and optionally trigger a hotplug mode event. Mode
setting for some fixed devices is simple enough to avoid the hotplug
event. In the hotplug event the mode line will be decoded, DDC queried,
etc. Some classes of devices (for example Intel 810,830,915) have to
have their mode set using vm86 and the video BIOS. Others might use a
small C app to query DDC and then use a device specific IOCTL to set
the mode registers. Early boot and normal user space will use the same
hotplug apps so they need to be as small as possible (good luck IA64
and emu86).
8) Merged fbmode - per head mode lists will include merged fb modes if
the other heads aren't in use. Setting a merged fb mode will lock out
the other head devices. It was decided that this was a better design
than having a control device.
9) printk - setting the mode will also record the fb location, size,
stride. Combining this info with the current fbconsole code will allow
printk/oops to print in all modes.
10) a new system console UI is proposed. SysReq blanks the current
screen and replaces it with the system console. System console will
also support runing kdbg. Hit SysReq again and whatever you were doing
is restored. This operation does not change the video mode.
11) OOPs will cause an immediate screen clear and painting of the
system console including the OOPs data. It is not needed to change the
video mode. Further drawing to the screen will be blocked until SysReq
returns to normal operation if possible.
Alan Cox: No consensus on the screen clear bit - there are actually
reasons to argue against it.
JS: Maybe save the contents at OOPs time and hotkey back to it? This
assumes the system is stable enough to do the copy and access the
keyboard. Another idea: start painting the OOPs from the top without
clearing, hope useful userspace data is at the bottom?
12) interrupt time printk - certain hardware implements
non-interruptible operations. Most modern hardware does not do this.
For older hardware these non-interruptible operations will need to be
wrapped by the device driver. The complete data needed to finish the
operation will be provided in the IOCTL. Doing this enables an
interrupt time printk to call into the driver, make sure the hardware
is free by completing the pending operation, and then write to the
framebuffer. No older hardware currently implements this protection;
without this protection there is potential for locking the machine.
13) all of the features being discussed are implemented by a single
device driver plus a supporting set of library drivers. Multitasking of
multiple controlling device drivers for a single piece of hardware is
not allowed.
14) A new framebuffer memory manager is needed for mesa GL support. Ian
is working on it. The memory manager will be part of the support
library driver code.
15) Over time user space console will be moved to a model where VT's
are implemented in user space. This allows user space console access to
fully accelerated drawing libraries. This might allow removal of all of
the tty/vc layer code avoiding the need to fix it for SMP.
16) accelerated, kernel based console drivers are not easily written in
this model. The only in kernel operations are simple ones like
CR/scroll, clear, print text. It is possible to call existing DRM entry
points from a kernel thread, but the code needed is complex. Note that
only things like printk use this console so is there a real need for
acceleration?
17) A user space console implementation also makes supporting multiple
users on multiple heads/card easier. The kernel will not need to be
modified for multi-user VT support. User mode console allows pretty
text and Asian scripts.
18) A coordinated system for grouping console devices needs to be
designed. This will be bad if each distro does it differently. One
proposal is to use udev to create: /console/1/mouse,
/console/1/keyboard, /console/1/usb_hub, /console/2/mouse,
/console/3/keyboard, /console/4/usb_hub, etc.
Alan Cox: Another is to use namespace mounts
19) SAK - secure attention key. We forgot to talk about this so we need
a design.
Alan Cox: Falls straight out of having the kernel + helper mode setting
20) A PAM login would assign ownership of the console group devices to
the logged in user. A mechanism needs to be designed for assigning
ownership of secondary heads for the merged fb case. X should run as
the logged in user and not require root if the hardware allows.
21) It was also discussed the X should stop implementing OS level
features and instead use the features of the underlying OS. If the
underlying OS is lacking support the support would be implemented in a
library external to X. Examples of moving from X to OS support include:
PCI bus, input, console groupings, etc.
22) A goal this design is to discourage user space video driver
implementations when a kernel one exists. An example of this would be
X's radeon XAA driver. X would instead use the DRM driver via mesa.
23) The old schemes are not going to be removed. If your ancient 2D
card only has an fbdev and XAA driver it will still work. We're not
going to remove old drivers if new ones don't exist. But don't expect
the composting X server to turn your clunker 2D card in to a Radeon
X800.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Thu Jul 29 13:30:05 2004
In-Reply-To: <19d601c475a5$0128ef10$1e01a8c0@cnt496>
<165901c47559$547f3b20$1e01a8c0@cnt496>
<41090E02.7090307@sun.com> <19d601c475a5$0128ef10$1e01a8c0@cnt496>
On Thu, 2004-07-29 at 12:48, Carl Karsten wrote:
> > TinderClientModules/XMonolithic.pm has examples of adding settings to host.d
ef
> > Copy one of those and modify as necessary (changing "if (0)" to "if (1)" of
> course)
>
> Got it, I think:
>
> # Some common configuration options that are disabled by default.
> $hostdef = $hostdef . "#define HasFreetype2 NO \n";
> if (0) {
> $hostdef = $hostdef . "#define BuildXF86DRI NO\n";
> }
>
> If the cfk boxes go past 1h 45 min, it worked.
Please don't add custom hacks like this to make the build work. If the
build's broken (it is) it should show up so that we know we have to fix
it.
--
Date: Thu Jul 29 14:13:57 2004
Subject: [Xorg] cvs won't build on fat
Message-ID: <1a7c01c475b0$f3ad20c0$1e01a8c0@cnt496>
Trying to build on a fat fs - bombed trying to create a link:
make[2]: Entering directory `/mnt/hda2/temp/XMonolithic/xc/include'
+ mkdir -p ../exports/include/X11
+ cd ../exports/include/X11
+ rm -f DECkeysym.h
+ ln -s ../../../include/DECkeysym.h .
ln: creating symbolic link `./DECkeysym.h' to `../../../include/DECkeysym.h':
Operation not permitted
make[2]: *** [includes] Error 1
Makes sense, fat doesn't support links. Tinderbox build, so if this isn't
supported, I'll just pull that box.
Carl K
Date: Thu Jul 29 14:16:16 2004
Subject: [Xorg] dispatch.c:634: error: too few arguments to function
ÀlterSaveSetForClient'
Message-ID: <1a8501c475b1$469dbba0$1e01a8c0@cnt496>
cfk.cygwin tinderbox went from green to red:
http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=41&logfile=20040
729112936.log
make[5]: Entering directory
`/home/Administrator/xorg/tinderclient/XMonolithic/xc/programs/Xserver/dix'
rm -f atom.o
gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I../include -I../../../
exports/include/X11 -I../../../include/fonts -I../../../include/extensions

-I../../../programs/Xserver/Xext -I../../../programs/Xserver/lbx -I../../..
-I../../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE
-D_
X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURC
E=199309L -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DFD_SETSIZE=256
-DXResExtension -DSHAPE -DXI
NPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT
-DREN
DER -DRANDR -DXFIXES -DDAMAGE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSING
LED
EPTH -DXFree86Server

-DXWIN_CLIPBOARD
-DXWIN_MULTIWINDOW -DXWIN_MULTIWINDOWEXTWM
-D
DDXBEFORERESET -DINCLUDE_ALLOCA_H -DNDEBUG -DFUNCPROT
O=15 -DNARROWPROTO
atom.c
rm -f colormap.o

-D_
-DREN
LED

-DXWIN_CLIPBOARD
-D
O=15 -DNARROWPROTO
colormap.c
rm -f cursor.o

-D_
-DREN
LED

-DXWIN_CLIPBOARD
-D
O=15 -DNARROWPROTO
cursor.c
rm -f devices.o

-D_
-DREN
LED

-DXWIN_CLIPBOARD
-D
O=15 -DNARROWPROTO
devices.c
rm -f dispatch.o

-D_
-DREN
LED

-DXWIN_CLIPBOARD
-D
O=15 -DNARROWPROTO
dispatch.c
dispatch.c: In function `ProcChangeSaveSet':
dispatch.c:634: error: too few arguments to function ÀlterSaveSetForClient'
dispatch.c: In function ÌnitClient':
dispatch.c:3727: warning: assignment from incompatible pointer typeCarl K
From Stuart.Kreitman at Sun.COM Thu Jul 29 14:45:16 2004
Date: Thu Jul 29 14:46:02 2004
In-Reply-To: <1a8501c475b1$469dbba0$1e01a8c0@cnt496>
References: <1a8501c475b1$469dbba0$1e01a8c0@cnt496>
Message-ID: <41096FEC.7020505@sun.com>
Carl:
I comitted this change to dispatch.c and dixutils.c at the same time. it
*shouldn't* be broken.
Look at dixutils.c:AlterSaveSetForClient(). If it doesn't have 5
arguments, do an update.
skk
Carl Karsten wrote:
>cfk.cygwin tinderbox went from green to red:
>http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=41&logfile=2004
0729112936.log
>make[5]: Entering directory
>`/home/Administrator/xorg/tinderclient/XMonolithic/xc/programs/Xserver/dix'
>rm -f atom.o
>gcc -c -O2 -fno-strength-reduce -Wall -Wpointer-arith -I../include -I../../..
/
>exports/include/X11 -I../../../include/fonts -I../../../include/extensions

> -I../../../programs/Xserver/Xext -I../../../programs/Xserver/lbx -I../../..

>-I../../../exports/include -D__i386__ -DWIN32_LEAN_AND_MEAN -DX_LOCALE
-D_
>X86_ -D__CYGWIN__ -D_XOPEN_SOURCE -D_POSIX_C_SOURC
> -D_SVID_SOURCE -D_GNU_SOURCE -DFD_SETSIZE=256
>NPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT
-DREN
>DER -DRANDR -DXFIXES -DDAMAGE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSING
LED
>EPTH -DXFree86Server

> -DXWIN_CLIPBOARD
-D
>DDXBEFORERESET -DINCLUDE_ALLOCA_H -DNDEBUG -D
FUNCPROTO=15 -DNARROWPROTO
>atom.c
>rm -f colormap.o
/


-D_
-DREN
LED

> -DXWIN_CLIPBOARD
-D
>colormap.c
>rm -f cursor.o
/


-D_
-DREN
LED

> -DXWIN_CLIPBOARD
-D
>cursor.c
>rm -f devices.o
/


-D_
-DREN
LED

> -DXWIN_CLIPBOARD
-D
>devices.c
>rm -f dispatch.o
/


-D_
-DREN
LED

> -DXWIN_CLIPBOARD
-D
>dispatch.c
>dispatch.c: In function `ProcChangeSaveSet':
>dispatch.c:634: error: too few arguments to function ÀlterSaveSetForClient'
>dispatch.c: In function ÌnitClient':
>dispatch.c:3727: warning: assignment from incompatible pointer typeCarl K
>
>_______________________________________________
>xorg mailing list
>
>
From Alexander.Gottwald at s1999.tu-chemnitz.de Thu Jul 29 14:46:19 2004
Date: Thu Jul 29 14:46:43 2004
In-Reply-To: <1a8501c475b1$469dbba0$1e01a8c0@cnt496>
References: <1a8501c475b1$469dbba0$1e01a8c0@cnt496>
Carl Karsten wrote:
> cfk.cygwin tinderbox went from green to red:
> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=41&logfile=200
40729112936.log
> make[5]: Entering directory
> -DXWIN_CLIPBOARD
-D
> DDXBEFORERESET -DINCLUDE_ALLOCA_H -DNDEBUG -D
> dispatch.c
> dispatch.c: In function `ProcChangeSaveSet':
> dispatch.c:634: error: too few arguments to function ÀlterSaveSetForClient'
> dispatch.c: In function ÌnitClient':
> dispatch.c:3727: warning: assignment from incompatible pointer type
the cvs checkout was done while the damage/xfixes import was not finished.
A later checkout was ok (except a minor build glitch which I'm commiting
right now)
bye
ago
NP: Foo Fighters - Breakout
--
Date: Thu Jul 29 15:15:25 2004
Thanks for posting this, Jon. I'll show it to some of the gfx guys around
here to see if they have any comments too.
On Thursday, July 29, 2004 12:46 pm, Jon Smirl wrote:
> 1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
> track the boot video device and expose the contents of C000:0 for that
> special case.
We already have config space exported via sysfs, so adding PCI ROM support
shouldn't be too hard. I think you mentioned a quirk for cards whose ROMs
are embedded somewhere in system firmware space--I think that'll work too.
> 2) VGA control - there needs to be a device for coordinating this. It
> would ensure that only a single VGA device gets enabled at a time. It
> would also adjust PCI bus routing as needed. It needs commands for
> disabling all VGA devices and then enabling a selected one. This device
> may need to coordinate with VGA console. You have to use this device
> even if you aren't using VGA console since it ensures that only a
> single VGA device gets enabled.
> Alan Cox: what about hardware that supports multiple vga routers? do we
> care?
Are you thinking of something like /dev/vga that you'd ioctl to select a
device?
> 3) Secondary card reset - Handled by an initial hotplug event. We need
> a volunteer to write clean vm86 and emu86 apps for running the ROM
> initialization. Resetting needs #1 and #2 to work since resetting a
> card will enable it's VGA mode. I have an implementation of this but it
> needs a lot of clean up.
In my case, I'll need it even for primary card reset. :) Can you post a link
to your old code? I'd be interested in checking it out even if it's not the
package we settle on (I think Alan mentioned switching to qemu at some
point?).
> 4) DRM code reorganization. There were several requests to reorganize
> DRM to more closely follow the Linux kernel guidelines. This
> reorganization should occur before new features are added.
Yay! The sooner, the better, IMO.
> 5) Multihead cards will expose one device file per head. Many IOCTLs
> exposed by these devices will be common. Some, like mode setting, will
> be per head.
This makes sense to me.
> 6) Mode setting before early user space - this was decided to be a
> platform specific problem. With minor adjustment the kernel can be made
> to boot without printing anything except errors before early user space
> starts. Platform specific code will need to handle these error messages
> if any. This includes INT10, Openfirmware, mainframe serial consoles,
> VGA mode. Suppressing informatory printing before early user space
> starts allows a clean boot straight into graphics mode.
Since, for the most part, this is already platform specific (i.e. many
platforms use vgacon if their cards have been POSTed by the BIOS, others use
firmware based printk, and still others use serial consoles), it seems
sensible. And we can always fall back to static, simple mode setting for
vgacon-like early output.
> 7) Mode setting from normal user space - devices will have a standard
> IOCTL accepting a mode string like fbdev currently uses. This IOCTL
> will lock the device and optionally trigger a hotplug mode event. Mode
> setting for some fixed devices is simple enough to avoid the hotplug
> event. In the hotplug event the mode line will be decoded, DDC queried,
> etc. Some classes of devices (for example Intel 810,830,915) have to
> have their mode set using vm86 and the video BIOS. Others might use a
> small C app to query DDC and then use a device specific IOCTL to set
> the mode registers. Early boot and normal user space will use the same
> hotplug apps so they need to be as small as possible (good luck IA64
> and emu86).
Heh. It shouldn't be too bad. We have lots of memory to waste on initrds. :)
> 21) It was also discussed the X should stop implementing OS level
> features and instead use the features of the underlying OS. If the
> underlying OS is lacking support the support would be implemented in a
> library external to X. Examples of moving from X to OS support include:
> PCI bus, input, console groupings, etc.
Again, yay!
Thanks,
Jesse
Date: Thu Jul 29 15:18:22 2004
On Wed, 2004-07-28 at 18:30 -0700, Jesse Barnes wrote:
>
> When I use the ati driver (specified in my xorg.conf file), it seems that the
> driver starts up but doesn't want to talk to my card.
>
> When I try the fbdev driver, the X server seems to start and run ok, but I get

> no output on the screen.
[...]
> (--) PCI: (0:16:0) unknown vendor (0x0210) [...]
^^^^
For one, this is backwards, ATI's vendor ID is 0x1002. Looks like debrix
doesn't deal with endianness correctly yet.
--
Date: Thu Jul 29 16:16:04 2004
<165901c47559$547f3b20$1e01a8c0@cnt496>
<1091132997.928.6.camel@leguin>
Message-ID: <1b3f01c475c2$00d104e0$1e01a8c0@cnt496>
----- Original Message -----
From: "Eric Anholt" <eta@lclark.edu>
To: "Carl Karsten" <carl@personnelware.com>
Cc: "Alan Coopersmith" <alan.coopersmith@sun.com>; "Alexander Gottwald"
<alexander.gottwald@s1999.tu-chemnitz.de>; <xorg@freedesktop.org>
Sent: Thursday, July 29, 2004 3:29 PM
Subject: Re: [Xorg] tinderboxs need tweeks
> On Thu, 2004-07-29 at 12:48, Carl Karsten wrote:
> > > TinderClientModules/XMonolithic.pm has examples of adding settings to
host.def
> > > Copy one of those and modify as necessary (changing "if (0)" to "if (1)"
of
> > course)
> >
> > Got it, I think:
> >
> > # Some common configuration options that are disabled by default.
> > $hostdef = $hostdef . "#define HasFreetype2 NO \n";
> > if (0) {
> > $hostdef = $hostdef . "#define BuildXF86DRI NO\n";
> > }
> >
> > If the cfk boxes go past 1h 45 min, it worked.
>
> Please don't add custom hacks like this to make the build work. If the
> build's broken (it is) it should show up so that we know we have to fix
> it.
Sorry, just following Alan's directions. pulled and restared.
Carl K
Date: Thu Jul 29 16:19:56 2004
<165901c47559$547f3b20$1e01a8c0@cnt496>
<1091132997.928.6.camel@leguin>
Message-ID: <41098613.20902@Sun.COM>
Eric Anholt wrote:
>> $hostdef = $hostdef . "#define HasFreetype2 NO \n";
>
> Please don't add custom hacks like this to make the build work. If the
> build's broken (it is) it should show up so that we know we have to fix
> it.
That's not a custom hack - that's a known issue even in the R6.7.0 release.
If your OS file has HasFreetype2 YES, but your freetype2 is too old, it won't
build without the above. Until someone fixes that issue, the above line is
the only way to make sure the rest of the build works on the OS.
--
Date: Thu Jul 29 16:26:01 2004
<165901c47559$547f3b20$1e01a8c0@cnt496>
<1091132997.928.6.camel@leguin> <41098613.20902@Sun.COM>
Message-ID: <1b7201c475c3$65d97880$1e01a8c0@cnt496>
> >> $hostdef = $hostdef . "#define HasFreetype2 NO \n";
> >
> > Please don't add custom hacks like this to make the build work. If the
> > build's broken (it is) it should show up so that we know we have to fix
> > it.
>
> That's not a custom hack - that's a known issue even in the R6.7.0 release.
> If your OS file has HasFreetype2 YES, but your freetype2 is too old, it won't
> build without the above. Until someone fixes that issue, the above line is
> the only way to make sure the rest of the build works on the OS.
>
lol - I figured this would happen. So back in it goes.
Or, what does it take to update a gentoo or mandrake box?
People on both #gentoo and #mandrake claim I have the newest free type there is.
Carl K
Date: Thu Jul 29 16:38:01 2004
Subject: [Xorg] gcc: miext/damage/libdamage.a: No such file or directory
Message-ID: <1b9501c475c5$1398bac0$1e01a8c0@cnt496>
729123638.log
`/home/carl/xorg/tinderclient/XMonolithic/xc/programs/Xserver/hw/dmx'
gcc -m32 -o
Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpoint
er-arith -Wundef -L../../exports/lib xkb/xf86KillSrv.o xkb/xf86VT.o
xkb/xf86Private.o ../../programs/Xserver/hw/xfree86/common/xf86Init.o
../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
../../programs/Xserver/hw/xfree86/parser/libxf86config.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
../../programs/Xserver/hw/xfree86/loader/libloader.a
../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a os/libos.a
../../lib/font/fontbase.o ../../lib/font/libfontbase.a Xext/libe
xts.a
xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a
../../programs/Xserver/hw/xfree86/common/libxf86.a Xext/libexts.a
xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
xfixes/libxfixes.a damageext/libdamage.a miext/damage/libdamage.a
dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a
lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a
render/librender.a xfixes/libxfixes.a damageext/libdamage.a
miext/damage/libdamage.a
../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
-
lXau -lXdmcp -rdynamic -ldl -Wl,-rpath-link,../../exports/lib
gcc: miext/damage/libdamage.a: No such file or directory
gcc: miext/damage/libdamage.a: No such file or directory
make[4]: *** [Xorg] Error 1
`/home/carl/xorg/tinderclient/XMonolithic/xc/programs/Xserver'Carl K
From miles.lane at comcast.net Thu Jul 29 13:39:28 2004
From: miles.lane at comcast.net (Miles Lane)
Date: Thu Jul 29 16:41:54 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has no member
named `find_sbit_image'
Message-ID: <41096080.8000902@comcast.net>
gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
-pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
-I/usr/include/freetype2/config -I. -I../../../include/fonts
-I../include -I../../../exports/include/X11
-I../../../programs/Xserver/include -I../../../exports/include
-I../../.. -I../../../exports/include -Dlinux -D__i386__
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE
-DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV
-DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER
-DXFree86Server -DXF86VIDMODE -DXvMCExtension
-DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86_FT2
ftfuncs.c
make[4]: *** [ftfuncs.o] Error 1
make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
Date: Thu Jul 29 16:43:41 2004
<1091139470.24950.160.camel@localhost>
On Fri, Jul 30, 2004 at 12:17:50AM +0200, Michel D?nzer wrote:
> On Wed, 2004-07-28 at 18:30 -0700, Jesse Barnes wrote:
> > When I use the ati driver (specified in my xorg.conf file), it seems that th
e
> > driver starts up but doesn't want to talk to my card.
> >
> > When I try the fbdev driver, the X server seems to start and run ok, but I g
et
> > no output on the screen.
>
> [...]
>
> > (--) PCI: (0:16:0) unknown vendor (0x0210) [...]
> ^^^^
> For one, this is backwards, ATI's vendor ID is 0x1002. Looks like debrix
> doesn't deal with endianness correctly yet.
Huh, weird. We should be setting X_ENDIAN_ORDER right in configure.ac;
I'll need to look into this at some stage.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/3c16e144/attach
ment.pgp
Date: Thu Jul 29 17:12:10 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has no member
named `find_sbit_image'
In-Reply-To: <41096080.8000902@comcast.net>
References: <41096080.8000902@comcast.net>
Message-ID: <a728f9f9040729164566255ff@mail.gmail.com>
On Thu, 29 Jul 2004 16:39:28 -0400, Miles Lane <miles.lane@comcast.net> wrote:
> gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> -I/usr/include/freetype2/config -I. -I../../../include/fonts
> -I../include -I../../../exports/include/X11
> -I../../../programs/Xserver/include -I../../../exports/include
> -I../../.. -I../../../exports/include -Dlinux -D__i386__
> -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
> -D_SVID_SOURCE -D_GNU_SOURCE
> -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV
> -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER
> -DXFree86Server -DXF86VIDMODE -DXvMCExtension
> -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
> -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
> 10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86_FT2
> ftfuncs.c
> ftfuncs.c: In function `FT_Do_SBit_Metrics':
> ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
> make[4]: *** [ftfuncs.o] Error 1
> make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
either upgrade to freetype 2.1.8 or add:
to your host.def
Alex
From Stuart.Kreitman at sun.com Thu Jul 29 16:50:04 2004
From: Stuart.Kreitman at sun.com (Stuart Kreitman)
Date: Thu Jul 29 17:14:20 2004
Subject: [Xorg] gcc: miext/damage/libdamage.a: No such file or directory
In-Reply-To: <1b9501c475c5$1398bac0$1e01a8c0@cnt496>
References: <1b9501c475c5$1398bac0$1e01a8c0@cnt496>
Message-ID: <41098D2C.4050401@sun.com>
Carl:
Please refer to my email 1hr ago Subject: "Please update tinderclient
scripts..."
thanks,
skk
Carl Karsten wrote:
>http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=43&logfile=2004
0729123638.log
>make[5]: Leaving directory
>`/home/carl/xorg/tinderclient/XMonolithic/xc/programs/Xserver/hw/dmx'
>gcc -m32 -o
>Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpoin
t
>er-arith -Wundef -L../../exports/lib xkb/xf86KillSrv.o xkb/xf86VT.o
>xkb/xf86Private.o ../../programs/Xserver/hw/xfree86/common/xf86Init.o
>../../programs/Xserver/hw/xfree86/common/xf86IniExt.o
>../../programs/Xserver/hw/xfree86/common/libxf86.a
>../../programs/Xserver/hw/xfree86/parser/libxf86config.a
>../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a
>../../programs/Xserver/hw/xfree86/loader/libloader.a
>../../programs/Xserver/hw/xfree86/common/libxf86.a dix/libdix.a os/libos.a
>../../lib/font/fontbase.o ../../lib/font/libfontbase.a Xext/libe
xts.a
>xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
>../../lib/lbxutil/liblbxutil.a
>../../programs/Xserver/hw/xfree86/common/libxf86.a Xext/libexts.a
>xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
>../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a
>xfixes/libxfixes.a damageext/libdamage.a miext/damage/libdamage.a
>dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a
>lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a
>render/librender.a xfixes/libxfixes.a damageext/libdamage.a
>miext/damage/libdamage.a
>../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a -lz -lm
-
>lXau -lXdmcp -rdynamic -ldl -Wl,-rpath-link,../../exports/lib
>gcc: miext/damage/libdamage.a: No such file or directory
>gcc: miext/damage/libdamage.a: No such file or directory
>make[4]: *** [Xorg] Error 1
>make[4]: Leaving directory
>`/home/carl/xorg/tinderclient/XMonolithic/xc/programs/Xserver'Carl K
>
>_______________________________________________
>xorg mailing list
>
>
Date: Thu Jul 29 17:33:51 2004
--- Jesse Barnes <jbarnes@engr.sgi.com> wrote
> In my case, I'll need it even for primary card reset. :) Can you
> post a link
> to your old code? I'd be interested in checking it out even if it's
> not the
> package we settle on (I think Alan mentioned switching to qemu at
> some
> point?).
I pushed a copy to bk://mesa3d@bkbits.net/boot
The code is a mess but I did get it working for a radeon. It needs the
VGA control and ROM fetch IOCTLs in the included DRM driver to work. It
is also built around libsysfs and klibc. I included copies of those.
The DRM driver has also been modified to generate a hotplug event.
You need a link in the hotplug directory to locate the reset program.
/etc/hotplug.d/dri/v86bios.hotplug -> /home/mesa/boot/v86bios/v86bios
The original source of this code is x86emu-0.8.tar.gz from Scitech. The
comments indicate that Egbert Eich wrote it. But after talking to
Egbert he seemed to wish that he hadn't.
This code does show that the basic architecture can work. For the
offical solution we need:
1) ROM access from sysfs
2) the VGA control device
3) klibc in the kernel build (it will be there in a few weeks)
4) not sure what to do about libsysfs, I find it pretty useless. It is
statically linked currently.
5) The current DRM driver needs to add a couple of lines of code that
generate the hotplug event. I already had GregKH modify class_simple so
that adding the event is easy. Other things DRM needs:
a) a lock to serialize resets if the driver is handling more than one
card
b) some mechanism to know that the hotplug event is finished to release
the lock. There may be a way to do this via the hotplug API or the
reset app can IOCTL the driver.
c) DRM needs to be modified to permanently AddMap the registers and
framebuffer. Right now the X server roots around in user space and then
tells DRM where the registers and fb are. Duh - DRM obviously knows
where these are without being told from user space. You need these maps
in place so that the reset app can Map registers/fb.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Thu Jul 29 18:02:31 2004
In-Reply-To: <20040729234339.GC25118@fooishbar.org>
<1091139470.24950.160.camel@localhost>
<20040729234339.GC25118@fooishbar.org>
On Thursday, July 29, 2004 4:43 pm, Daniel Stone wrote:
> Huh, weird. We should be setting X_ENDIAN_ORDER right in configure.ac;
> I'll need to look into this at some stage.
It looks like part of the config is working, but some of it is broken:
jbarnes@mill:~/working/debrix--devel--0.1--patch-11$ grep -r ENDIAN include/*
include/config.h:#define WORDS_BIGENDIAN 1
include/config.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
include/config.h.in:#undef WORDS_BIGENDIAN
include/debrix.h:#define WORDS_BIGENDIAN 1
include/debrix.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
include/servermd.h:#if defined(__BIG_ENDIAN__)
Jesse
Date: Thu Jul 29 18:09:12 2004
--- Jesse Barnes <jbarnes@engr.sgi.com> wrote:
> > 2) VGA control - there needs to be a device for coordinating this.
>
> Are you thinking of something like /dev/vga that you'd ioctl to
> select a device?
Probably, Alan Cox will probably make the final decision on that one.
This device needs calls to:
1) disable all VGA devices for sure.
2) enable a VGA device and make sure none of the other ones are
enabled.
3) maybe list all VGA devices, but you can do this via sysfs and the
pci space.
4) which device is the currently active device
5) monitor hotplug for new VGA devices or removal of one
6) anything else?
I tried playing with this and I actually got VGAcon to jump between two
cards. The VGA control code is in the DRM driver at
bk://mesa3d@bkbits.net/drm.
It would be cool to set the console onto a CompactFlash/Cardbus VGA
card, then pull the card out and have the console automatically move to
the laptop display. Google around there are several laptop video cards available
.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Thu Jul 29 18:10:26 2004
Message from yahoo.com.
Unable to deliver message to the following address(es).
<xorg-xserver@freedesktop.org>:
131.252.208.82 does not like recipient.
Remote host said: 550 <xorg-xserver@freedesktop.org>: Recipient address
rejected: User unknown in
local recipient table
Giving up on 131.252.208.82.
--- Original message follows.
Return-Path: <jonsmirl@yahoo.com>
--- Ely Levy <elylevy@cs.huji.ac.il> wrote:
> Hey,
> I remember a while ago there was a talk about locking one of the
> devices
> so only one user can open it. This to prevent anyone else (even with
> root
> accesss?) from seeing your screen.
> is it still planned? is it solved by some other way?
I don't think there is any way to lock out root. Root can always open
/dev/mem and get to the framebuffer. Even if we lock that down, root
can modprobe in their own device driver.
It should be possible to lock out non-root users.
SE Linux should provide more control over what root can do, but I don't
know enough about it. If you figure out how to lock out root please let
me know.
> Another thing was the discussion about making sure that you are
> entering
> your login to X or console and not to some trojan.
> Does it address this as well?
Alan Cox says this is covered but I'm not clear on how he is going to
achieve it.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Thu Jul 29 18:14:28 2004
<20040729234339.GC25118@fooishbar.org>
On Thursday, July 29, 2004 5:44 pm, Jesse Barnes wrote:
> On Thursday, July 29, 2004 4:43 pm, Daniel Stone wrote:
> > Huh, weird. We should be setting X_ENDIAN_ORDER right in configure.ac;
> > I'll need to look into this at some stage.
>
> It looks like part of the config is working, but some of it is broken:
>
> jbarnes@mill:~/working/debrix--devel--0.1--patch-11$ grep -r ENDIAN
> include/* include/config.h:#define WORDS_BIGENDIAN 1
> include/config.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
> include/config.h.in:#undef WORDS_BIGENDIAN
> include/debrix.h:#define WORDS_BIGENDIAN 1
> include/debrix.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
> include/servermd.h:#if defined(__BIG_ENDIAN__)
After fixing these up by hand, things get a little further--the server hangs
right after loading the vgahw module.
Jesse
From seemant at gentoo.org Thu Jul 29 18:40:18 2004
From: seemant at gentoo.org (Seemant Kulleen)
Date: Thu Jul 29 18:56:48 2004
In-Reply-To: <1b7201c475c3$65d97880$1e01a8c0@cnt496>
<165901c47559$547f3b20$1e01a8c0@cnt496>
<1091132997.928.6.camel@leguin> <41098613.20902@Sun.COM>
<1b7201c475c3$65d97880$1e01a8c0@cnt496>
Message-ID: <1091151618.18398.4.camel@sephora>
> Or, what does it take to update a gentoo or mandrake box?
> People on both #gentoo and #mandrake claim I have the newest free type there i
s.
Carl, what version of freetype do you have on your gentoo box?
--
"Check out the hook while my DJ revolves it"
Seemant Kulleen
http://dev.gentoo.org/~seemant
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x3458780E
Key fingerprint = 23A9 7CB5 9BBB 4F8D 549B 6593 EDA2 65D8 3458 780E
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040729/5249602d/attach
ment.pgp
From nbensa at gmx.net Thu Jul 29 19:06:25 2004
Date: Thu Jul 29 19:06:50 2004
In-Reply-To: <1091151618.18398.4.camel@sephora>
<1b7201c475c3$65d97880$1e01a8c0@cnt496>
<1091151618.18398.4.camel@sephora>
Seemant Kulleen wrote:
> > Or, what does it take to update a gentoo or mandrake box?
> > People on both #gentoo and #mandrake claim I have the newest free type
> > there is.
>
> Carl, what version of freetype do you have on your gentoo box?
If he's running ~x86, 2.1.5-r1
2.1.9 is the latest; I guess Gentoo is not the bleeding edge distro it used to
be...
Regards,
Norberto
From roland.mainz at nrubsig.org Thu Jul 29 18:20:04 2004
Date: Thu Jul 29 19:21:09 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has no
membernamed `find_sbit_image'
<a728f9f9040729164566255ff@mail.gmail.com>
Message-ID: <4109A244.B7B42E82@nrubsig.org>
Alex Deucher wrote:
>
> On Thu, 29 Jul 2004 16:39:28 -0400, Miles Lane <miles.lane@comcast.net> wrote:
> > gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> > -I/usr/include/freetype2/config -I. -I../../../include/fonts
> > -I../include -I../../../exports/include/X11
> > -I../../../programs/Xserver/include -I../../../exports/include
> > -I../../.. -I../../../exports/include -Dlinux -D__i386__
> > -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
> > -D_SVID_SOURCE -D_GNU_SOURCE
> > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV
> > -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER
> > -DXFree86Server -DXF86VIDMODE -DXvMCExtension
> > -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
> > -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
> > 10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86_FT2
> > ftfuncs.c
> > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
> > make[4]: *** [ftfuncs.o] Error 1
> > make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
>
> either upgrade to freetype 2.1.8 or add:
> to your host.def
Or build the freetype2 version in the xc/-tree statically into the
applications...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Thu Jul 29 19:27:48 2004
References: <10ca01c474d3$1f1fdd80$1e01a8c0@cnt496><1b7201c475c3$65d97880$1e01a8
c0@cnt496>
<1091151618.18398.4.camel@sephora>
<200407292306.26072.nbensa@gmx.net>
Message-ID: <1cd001c475dc$cacf88b0$1e01a8c0@cnt496>
----- Original Message -----
From: "Norberto Bensa" <nbensa@gmx.net>
To: <seemant@gentoo.org>
Cc: <xorg@freedesktop.org>; "Carl Karsten" <carl@personnelware.com>
Sent: Thursday, July 29, 2004 9:06 PM
Subject: Re: [Xorg] tinderboxs need tweeks
> Seemant Kulleen wrote:
> > > Or, what does it take to update a gentoo or mandrake box?
> > > People on both #gentoo and #mandrake claim I have the newest free type
> > > there is.
> >
> > Carl, what version of freetype do you have on your gentoo box?
>
> If he's running ~x86, 2.1.5-r1
yup
>
> 2.1.9 is the latest; I guess Gentoo is not the bleeding edge distro it used to
> be...
yup
Date: Thu Jul 29 19:47:36 2004
In-Reply-To: <4109A244.B7B42E82@nrubsig.org>
<4109A244.B7B42E82@nrubsig.org>
On Thu, 2004-07-29 at 18:20, Roland Mainz wrote:
> Alex Deucher wrote:
> >
> > On Thu, 29 Jul 2004 16:39:28 -0400, Miles Lane <miles.lane@comcast.net> wrot
e:
> > > gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > > -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> > > -I/usr/include/freetype2/config -I. -I../../../include/fonts
> > > -I../include -I../../../exports/include/X11
> > > -I../../../programs/Xserver/include -I../../../exports/include
> > > -I../../.. -I../../../exports/include -Dlinux -D__i386__
> > > -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
> > > -D_SVID_SOURCE -D_GNU_SOURCE
> > > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV
> > > -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER
> > > -DXFree86Server -DXF86VIDMODE -DXvMCExtension
> > > -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
> > > -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
> > > 10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86_FT2
> > > ftfuncs.c
> > > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
> > > make[4]: *** [ftfuncs.o] Error 1
> > > make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
> >
> > either upgrade to freetype 2.1.8 or add:
> > #define HasFreetype2 NO
> > to your host.def
>
> Or build the freetype2 version in the xc/-tree statically into the
> applications...
Or go and wrap the commit in tests for 2.1.8 being available, which
seems to be the clear solution:
revision 1.3
date: 2004/05/04 18:47:31; author: gisburn; state: Exp; lines: +161
-57
Fix for http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=307
- Restore optimization heuristics on CJK fonts in the FreeType font
module which were broken in X11R6.7. Patch by Chisato Yamauchi
<cyamauch@a.phys.nagoya-u.ac.jp>.
At least, as far as I can tell. I'm trying to fix other issues at the
moment.
--
From nbensa at gmx.net Thu Jul 29 20:05:51 2004
Date: Thu Jul 29 20:06:22 2004
In-Reply-To: <1cd001c475dc$cacf88b0$1e01a8c0@cnt496>
<200407292306.26072.nbensa@gmx.net>
<1cd001c475dc$cacf88b0$1e01a8c0@cnt496>
Carl Karsten wrote:
> From: "Norberto Bensa" <nbensa@gmx.net>
> > 2.1.9 is the latest; I guess Gentoo is not the bleeding edge distro it
> > used to be...
>
> yup
Hm, well, 2.1.9 is masked on Gentoo; I unmasked it, emerged it, and it's
working.
Date: Thu Jul 29 20:13:20 2004
In-Reply-To: <4109BA15.C8A0B052@nrubsig.org>
<1091155653.888.3.camel@leguin> <4109BA15.C8A0B052@nrubsig.org>
> > > > On Thu, 29 Jul 2004 16:39:28 -0400, Miles Lane <miles.lane@comcast.net>
wrote:
> > > > > gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > > > > -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> > > > > -I/usr/include/freetype2/config -I. -I../../../include/fonts
> > > > > -I../include -I../../../exports/include/X11
> > > > > -I../../../programs/Xserver/include -I../../../exports/include
> > > > > -I../../.. -I../../../exports/include -Dlinux -D__i386__
> > > > > -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOUR
CE
> > > > > -D_SVID_SOURCE -D_GNU_SOURCE
> > > > > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV
> > > > > -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER
> > > > > -DXFree86Server -DXF86VIDMODE -DXvMCExtension
> > > > > -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
> > > > > -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
> > > > > 10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86_F
T2
> > > > > ftfuncs.c
> > > > > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > > > > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > > > > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics
'
> > > > > make[4]: *** [ftfuncs.o] Error 1
> > > > > make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
> > > >
> > > > either upgrade to freetype 2.1.8 or add:
> > > > #define HasFreetype2 NO
> > > > to your host.def
> > >
> > > Or build the freetype2 version in the xc/-tree statically into the
> > > applications...
> >
> > Or go and wrap the commit in tests for 2.1.8 being available, which
> > seems to be the clear solution:
>
> That will _BREAK_ XTT like it happened in the last release. This should
> not happen again. Please link libFreeType2 statically if the platform
> really does not have Freetype2 >= 2.1.8 and cannot use the copy in the
> xc/-tree...
OK, I assumed from that changelog that an optimization was simply
removed by accident with all of the changes that had been going on in
freetype areas. Is there really no way to do this with older FreeType?
--
Date: Thu Jul 29 20:49:42 2004
In-Reply-To: <4109C01E.94C3E011@nrubsig.org>
<1091157194.888.6.camel@leguin> <4109C01E.94C3E011@nrubsig.org>
> > > > > Or build the freetype2 version in the xc/-tree statically into the
> > > > > applications...
> > > >
> > > > Or go and wrap the commit in tests for 2.1.8 being available, which
> > > > seems to be the clear solution:
> > >
> > > That will _BREAK_ XTT like it happened in the last release. This should
> > > not happen again. Please link libFreeType2 statically if the platform
> > > really does not have Freetype2 >= 2.1.8 and cannot use the copy in the
> > > xc/-tree...
> >
> > OK, I assumed from that changelog that an optimization was simply
> > removed by accident with all of the changes that had been going on in
> > freetype areas.
>
> That wasn't an accident. Initially it was removed because the XTT code
> was using a "private" Freetype2 API - but the side-effects were that
> drastic that the FreeType2 library got an extra "public" API to get the
> functionality back.
>
> > Is there really no way to do this with older FreeType?
>
> AFAIK not without causing trouble for CJKV users. Even Xfree86 has
> updated it's FreeType2 copy in CVS to FreeType 2.1.8 to ensure the XTT
> code works properly (using the new "public" API which was extra added
> for that purpose) - and AFAIK that indicates the importance of the
> issue...
"_BREAK_" implied something besides "things slow down (a lot)," so I
thought I had misunderstood. "Things slow down (a lot) for some fonts
when used as core fonts" is *far* better than "The build fails for
almost all of our users." Simply saying, "Use 2.1.8 if you want fast
CJKV core fonts" seems pretty simple to me.
--
Date: Thu Jul 29 21:04:26 2004
<4109A244.B7B42E82@nrubsig.org> <1091155653.888.3.camel@leguin>
Message-ID: <4109BA15.C8A0B052@nrubsig.org>
Eric Anholt wrote:
> > > On Thu, 29 Jul 2004 16:39:28 -0400, Miles Lane <miles.lane@comcast.net> wr
ote:
> > > > gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > > > -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> > > > -I/usr/include/freetype2/config -I. -I../../../include/fonts
> > > > -I../include -I../../../exports/include/X11
> > > > -I../../../programs/Xserver/include -I../../../exports/include
> > > > -I../../.. -I../../../exports/include -Dlinux -D__i386__
> > > > -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE
> > > > -D_SVID_SOURCE -D_GNU_SOURCE
> > > > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV
> > > > -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER
> > > > -DXFree86Server -DXF86VIDMODE -DXvMCExtension
> > > > -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
> > > > -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
> > > > 10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86_FT2
> > > > ftfuncs.c
> > > > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > > > ftfuncs.c:931: error: structure has no member named `find_sbit_image'
> > > > ftfuncs.c:955: error: structure has no member named `load_sbit_metrics'
> > > > make[4]: *** [ftfuncs.o] Error 1
> > > > make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
> > >
> > > either upgrade to freetype 2.1.8 or add:
> > > #define HasFreetype2 NO
> > > to your host.def
> >
> > Or build the freetype2 version in the xc/-tree statically into the
> > applications...
>
> Or go and wrap the commit in tests for 2.1.8 being available, which
> seems to be the clear solution:
That will _BREAK_ XTT like it happened in the last release. This should
not happen again. Please link libFreeType2 statically if the platform
really does not have Freetype2 >= 2.1.8 and cannot use the copy in the
xc/-tree...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Thu Jul 29 21:56:43 2004
<1091157194.888.6.camel@leguin>
Message-ID: <4109C01E.94C3E011@nrubsig.org>
Eric Anholt wrote:
>
> On Thu, 2004-07-29 at 20:01, Roland Mainz wrote:
> > Eric Anholt wrote:
> > > > > On Thu, 29 Jul 2004 16:39:28 -0400, Miles Lane <miles.lane@comcast.net
> wrote:
> > > > > > gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> > > > > > -pedantic -Wall -Wpointer-arith -Wundef -I/usr/include/freetype2
> > > > > > -I/usr/include/freetype2/config -I. -I../../../include/fonts
> > > > > > -I../include -I../../../exports/include/X11
> > > > > > -I../../../programs/Xserver/include -I../../../exports/include
> > > > > > -I../../.. -I../../../exports/include -Dlinux -D__i386__
> > > > > > -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SO
URCE
> > > > > > -D_SVID_SOURCE -D_GNU_SOURCE
> > > > > > -DFUNCPROTO=15 -DNARROWPROTO -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPR
IV
> > > > > > -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADE
R
> > > > > > -DXFree86Server -DXF86VIDMODE -DXvMCExtension
> > > > > > -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension
> > > > > > -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) *
> > > > > > 10000000) + ((7) * 100000) + ((0) * 1000) + 0)" -DXFREE86
_FT2
> > > > > > ftfuncs.c
> > > > > > ftfuncs.c: In function `FT_Do_SBit_Metrics':
> > > > > > ftfuncs.c:931: error: structure has no member named `find_sbit_image
'
> > > > > > ftfuncs.c:955: error: structure has no member named `load_sbit_metri
cs'
> > > > > > make[4]: *** [ftfuncs.o] Error 1
> > > > > > make[4]: Leaving directory `/usr/src/xc/lib/font/FreeType'
> > > > >
> > > > > either upgrade to freetype 2.1.8 or add:
> > > > > #define HasFreetype2 NO
> > > > > to your host.def
> > > >
> > > > Or build the freetype2 version in the xc/-tree statically into the
> > > > applications...
> > >
> > > Or go and wrap the commit in tests for 2.1.8 being available, which
> > > seems to be the clear solution:
> >
> > That will _BREAK_ XTT like it happened in the last release. This should
> > not happen again. Please link libFreeType2 statically if the platform
> > really does not have Freetype2 >= 2.1.8 and cannot use the copy in the
> > xc/-tree...
>
> OK, I assumed from that changelog that an optimization was simply
> removed by accident with all of the changes that had been going on in
> freetype areas.
That wasn't an accident. Initially it was removed because the XTT code
was using a "private" Freetype2 API - but the side-effects were that
drastic that the FreeType2 library got an extra "public" API to get the
functionality back.
> Is there really no way to do this with older FreeType?
AFAIK not without causing trouble for CJKV users. Even Xfree86 has
updated it's FreeType2 copy in CVS to FreeType 2.1.8 to ensure the XTT
code works properly (using the new "public" API which was extra added
for that purpose) - and AFAIK that indicates the importance of the
issue...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Thu Jul 29 22:00:47 2004
In-Reply-To: <4109C01E.94C3E011@nrubsig.org>
<4109BA15.C8A0B052@nrubsig.org> <1091157194.888.6.camel@leguin>
<4109C01E.94C3E011@nrubsig.org>
Message-ID: <20040730050045.GG25118@fooishbar.org>
On Fri, Jul 30, 2004 at 05:27:26AM +0200, Roland Mainz wrote:
> That wasn't an accident. Initially it was removed because the XTT code
> was using a "private" Freetype2 API - but the side-effects were that
> drastic that the FreeType2 library got an extra "public" API to get the
> functionality back.
No need for the quotes - it was a private API, and now it's public.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/493c1657/attach
ment.pgp
Date: Thu Jul 29 22:06:05 2004
<1091159377.888.16.camel@leguin>
Message-ID: <4109C8C7.2164E0F5@nrubsig.org>
Eric Anholt wrote:
> > AFAIK not without causing trouble for CJKV users. Even Xfree86 has
> > updated it's FreeType2 copy in CVS to FreeType 2.1.8 to ensure the XTT
> > code works properly (using the new "public" API which was extra added
> > for that purpose) - and AFAIK that indicates the importance of the
> > issue...
>
> "_BREAK_" implied something besides "things slow down (a lot)," so I
> thought I had misunderstood. "Things slow down (a lot) for some fonts
> when used as core fonts" is *far* better than "The build fails for
> almost all of our users." Simply saying, "Use 2.1.8 if you want fast
> CJKV core fonts" seems pretty simple to me.
I consider the fonts stuff "broken" when I have to wait minutes instead
of a few secs to load a font. The original issue resulted in a very
unfortunate flame war and I really do _NOT_ want that debate again.
If you really want an Imake flag for that then please make it an
equivalent for linking the tree copy of libFreeType2 statically.
Otherwise a very ugly bug creps back into the tree which was thought to
be fixed for the next Xorg release after X11R6.7.0 ...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Thu Jul 29 22:55:18 2004
Subject: [Xorg] cvs won't build on fat
In-Reply-To: Your message of "Thu, 29 Jul 2004 16:13:53 CDT."
<1a7c01c475b0$f3ad20c0$1e01a8c0@cnt496>
Message-ID: <E1BqQMH-00073Q-7c@evo.keithp.com>
Around 16 o'clock on Jul 29, "Carl Karsten" wrote:
> Makes sense, fat doesn't support links. Tinderbox build, so if this isn't
> supported, I'll just pull that box.
Imake supports using 'cp' instead of 'ln -s'; check that out before giving
up.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040729/d30071eb/attach
ment.pgp
Date: Thu Jul 29 23:16:40 2004
<4109C8C7.2164E0F5@nrubsig.org>
Message-ID: <E1BqQgc-00076j-5r@evo.keithp.com>
> I consider the fonts stuff "broken" when I have to wait minutes instead
> of a few secs to load a font. The original issue resulted in a very
> unfortunate flame war and I really do _NOT_ want that debate again.
> If you really want an Imake flag for that then please make it an
> equivalent for linking the tree copy of libFreeType2 statically.
Shipping code which has known build regressions in its default
configuration is not acceptable.
Forcing people to use a static copy of a soon-to-be-outdated version of
FreeType is similarly unacceptable.
Please fix the code or I will recommend that the whole patch be backed out.
I would fix it myself, but I'm afraid I will get it wrong as I have no
applications which I can easily configure to use core fonts.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040729/9f2eac81/attach
ment-0001.pgp
Date: Fri Jul 30 00:09:30 2004
Subject: [Xorg] Re: CVS Update: xc (branch: COMPOSITEWRAP)
In-Reply-To: <20040730065443.3C2589F917@freedesktop.org>
References: <20040730065443.3C2589F917@freedesktop.org>
On Thu, 2004-07-29 at 23:54, Eric Anholt wrote:
> Module name: xc
> Changes by: anholt@pdx. 04/07/29 23:54:43
>
> Log message:
> - Commit WIP of an integration of the Composite extension and a
> DDX-independent Composite wrapper. It's quite incomplete. Notably,
> the Render extension isn't wrapped properly or even completely
> wrapped improperly.
> - Rename COMPOSITE enum in smi driver to avoid conflict with new define.
> - Fix REGION_INIT usage of Damage so that it doesn't crash on first use.
> - Fix some apparent mismerges of XFIXES.
> - Fix some whitespace from DAMAGE-XFIXES merge that appears different
> from both xserver CVS and surrounding style.
This doesn't work yet. If you try it, expect pain and total failure to
render what you want, perhaps ending with crashing when it renders
somewhere you really don't want.
Oh, and it breaks the xf86cfg build somehow. I've been taking it out of
the build by editing .../xfree86/Imakefile until I get around to
figuring out why.
--
From spyderous at gentoo.org Fri Jul 30 00:44:33 2004
Date: Fri Jul 30 00:44:17 2004
In-Reply-To: <200407300005.52078.nbensa@gmx.net>
<200407292306.26072.nbensa@gmx.net>
<1cd001c475dc$cacf88b0$1e01a8c0@cnt496>
<200407300005.52078.nbensa@gmx.net>
On Thu, 2004-07-29 at 23:05, Norberto Bensa wrote:
> > From: "Norberto Bensa" <nbensa@gmx.net>
> > > 2.1.9 is the latest; I guess Gentoo is not the bleeding edge distro it
> > > used to be...
> >
> > yup
>
> Hm, well, 2.1.9 is masked on Gentoo; I unmasked it, emerged it, and it's
> working.
Be aware:
/usr/portage/profiles/package.mask:
# <foser@gentoo.org> (24 Feb 2004)
# breaks source builds
# needs fixes troughout the tree
# lot of testing needed
--
Donnie Berkholz
Gentoo Linux
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/1d9376cd/attach
ment.pgp
Date: Fri Jul 30 01:45:32 2004
In-Reply-To: keithp@keithp.com wrote on Thursday,
29 July 2004 at 23:16:10 -0700
References: <4109C8C7.2164E0F5@nrubsig.org> <E1BqQgc-00076j-5r@evo.keithp.com>
>
> Shipping code which has known build regressions in its default
> configuration is not acceptable.
>
> Forcing people to use a static copy of a soon-to-be-outdated version of
> FreeType is similarly unacceptable.
The above arguments don't seem to fit together:
One would expect that people interested in latest-and-greatest code
already have FreeType 2.1.8 installed.
People still using an older version are not expected to update to
a version higher than 2.1.8 later if they are not willing to update
to 2.1.8 now. For these the internally shipped version 2.1.8 would
give them the opportunity to use newer code than what they already
have.
>
> Please fix the code or I will recommend that the whole patch be backed out.
> I would fix it myself, but I'm afraid I will get it wrong as I have no
> applications which I can easily configure to use core fonts.
>
Keith,
it is appropriate to ask Chisato to #ifdef his code on the version of
FreeType however I feel it is not fair to threaten with the deletion
of his code.
Chisato Yamaushi's code patch created a dependecy to FreeType 2.1.8.
The inclusion of this code was a prerequisite for dropping the XTT
font renderer.
When we did the 6.7 release we created dependencies to FreeType 2.1.7
although most people had older versions of freetype installed. Still we
decided to turn off the use of 'internal' version of FreeType we
ship by default (at least on those platforms that usually ship FreeType)
for the arguments you stated above. Instead we decided to document
this dependency in the release notes and offer people to enable the
internal version of freetype as quick a workaround.
The majority of people active on this mailing list may not be affected
by the deletion of this patch. However a considerable group of people
would suffer tremendously. This group is largely silent on this forum.
This silence however does not proof that this group does not exist.
Not allowing these people to include their code with the same arguments
that have worked for us in a previous release and even threatening with
the removal of their code is inappropriate.
Egbert.
Date: Fri Jul 30 03:29:33 2004
On Gwe, 2004-07-30 at 02:09, Jon Smirl wrote:
> 1) disable all VGA devices for sure.
> 2) enable a VGA device and make sure none of the other ones are
> enabled.
> 3) maybe list all VGA devices, but you can do this via sysfs and the
> pci space.
> 4) which device is the currently active device
> 5) monitor hotplug for new VGA devices or removal of one
> 6) anything else?
I wasn't planning to put the hotplug part into the kernel vga switch
code, but that does belong in the frame buffer. The implementation
I anticipated was essentially
take vga routing to card {n} and lock (blocking)
take vga routing to card {n} and lock (nonblocking)
free vga routing lock
with multiple people being able to take the lock at once for the same
card and automatically losing the lock on file close/program exit. The
API also has to be available to the kernel.
Date: Fri Jul 30 03:33:09 2004
On Gwe, 2004-07-30 at 02:10, Jon Smirl wrote:
> > Another thing was the discussion about making sure that you are
> > entering
> > your login to X or console and not to some trojan.
> > Does it address this as well?
>
> Alan Cox says this is covered but I'm not clear on how he is going to
> achieve it.
We get it for free once mode restore without X is doable. SAK is already
in kernel, its just not useful with the current X setup.
Date: Fri Jul 30 03:56:51 2004
<1091159377.888.16.camel@leguin>
On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
>
> "Things slow down (a lot) for some fonts when used as core fonts" is
> *far* better than "The build fails for almost all of our users."
> Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> pretty simple to me.
Seconded, FWIW.
--
From roland.mainz at nrubsig.org Fri Jul 30 04:04:34 2004
Date: Fri Jul 30 05:07:25 2004
<1091159377.888.16.camel@leguin> <1091184967.24948.182.camel@localhost>
Message-ID: <410A2B42.F8C0583F@nrubsig.org>
Michel D?nzer wrote:
>
> On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
> >
> > "Things slow down (a lot) for some fonts when used as core fonts" is
> > *far* better than "The build fails for almost all of our users."
> > Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> > pretty simple to me.
>
> Seconded, FWIW.
So you think it's acceptable to slap the users in asia into the face or
what ? Those users get a font loading performance which is *NOT*
acceptable if that code gets removed again.
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From matthieu.herrb at laas.fr Fri Jul 30 05:32:09 2004
Date: Fri Jul 30 05:32:15 2004
In-Reply-To: <410A2B42.F8C0583F@nrubsig.org>
References: <41096080.8000902@comcast.net> <a728f9f9040729164566255ff@mail.
gmail.com> <4109A244.B7B42E82@nrubsig.org> <1091155653.888.3.camel@leguin>
<4109C01E.94C3E011@nrubsig.org> <1091159377.888.16.camel@leguin>
<1091184967.24948.182.camel@localhost>
<410A2B42.F8C0583F@nrubsig.org>
Message-ID: <410A3FC9.9050905@laas.fr>
Roland Mainz wrote:
> Michel D?nzer wrote:
>
>>On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
>>
>>>"Things slow down (a lot) for some fonts when used as core fonts" is
>>>*far* better than "The build fails for almost all of our users."
>>>Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
>>>pretty simple to me.
>>
>>Seconded, FWIW.
>
>
> So you think it's acceptable to slap the users in asia into the face or
> what ? Those users get a font loading performance which is *NOT*
> acceptable if that code gets removed again.
>
I'd suggest to let imake detect the version of the installed Freetype,
and then disable the offending code if the installed version is too old.
BTW, another problem seem to be that mozilla (and thunderbird) builds
fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
known workaround for that?
--
Matthieu Herrb
-------------- next part --------------
Name: smime.p7s
Size: 4071 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/8419b736/smime.
bin
Date: Fri Jul 30 05:38:47 2004
<20040729234339.GC25118@fooishbar.org>
On Thu, 2004-07-29 at 18:14 -0700, Jesse Barnes wrote:
> On Thursday, July 29, 2004 5:44 pm, Jesse Barnes wrote:
> > On Thursday, July 29, 2004 4:43 pm, Daniel Stone wrote:
> > > Huh, weird. We should be setting X_ENDIAN_ORDER right in configure.ac;
> > > I'll need to look into this at some stage.
> >
> > It looks like part of the config is working, but some of it is broken:
> >
> > jbarnes@mill:~/working/debrix--devel--0.1--patch-11$ grep -r ENDIAN
> > include/* include/config.h:#define WORDS_BIGENDIAN 1
> > include/config.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
> > include/config.h.in:#undef WORDS_BIGENDIAN
> > include/debrix.h:#define WORDS_BIGENDIAN 1
> > include/debrix.h:#define X_BYTE_ORDER X_LITTLE_ENDIAN
> > include/servermd.h:#if defined(__BIG_ENDIAN__)
>
> After fixing these up by hand, things get a little further--the server hangs
> right after loading the vgahw module.
I guess that needs more endianness/powerpc specific fixing.
What about the fbdev driver?
--
Date: Fri Jul 30 05:44:31 2004
Subject: [Xorg] CVS HEAD -- ftfuncs.c:931: error: structure has
nomembernamed `find_sbit_image'
References: <41096080.8000902@comcast.net> <a728f9f9040729164566255ff@mail.
gmail.com> <4109A244.B7B42E82@nrubsig.org> <1091155653.888.3.camel@leguin>
<1091184967.24948.182.camel@localhost>
<410A2B42.F8C0583F@nrubsig.org> <410A3FC9.9050905@laas.fr>
Message-ID: <410A42A1.926C53EA@nrubsig.org>
Matthieu Herrb wrote:
> >>>"Things slow down (a lot) for some fonts when used as core fonts" is
> >>>*far* better than "The build fails for almost all of our users."
> >>>Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> >>>pretty simple to me.
> >>
> >>Seconded, FWIW.
> >
> > So you think it's acceptable to slap the users in asia into the face or
> > what ? Those users get a font loading performance which is *NOT*
> > acceptable if that code gets removed again.
>
> I'd suggest to let imake detect the version of the installed Freetype,
> and then disable the offending code if the installed version is too old.
That's the option I'd like to avoid. Just think about it: The last
release (="Xorg release 6.7.0") made Freetyppe 2.1.7 _mandatory_. So why
it is a problem to make FreeType 2.1.8 mandatory (one revision newer
than the previous release "minimum" version) for the next "major"
release - "6.8.0". Otherwise we can really call it "Xorg release 6.7.1"
... =:-)
> BTW, another problem seem to be that mozilla (and thunderbird) builds
> fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
> and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
> known workaround for that?
Not really. Someone wrote patches but they only work with FreeType
2.1.8. That's why I start to like the idea with linking the library
statically into the font code, otherwise the next FreeType2 release may
cause headache again...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Fri Jul 30 06:04:05 2004
In-Reply-To: <410A42A1.926C53EA@nrubsig.org>
<a728f9f9040729164566255ff@mail.gmail.com> <4109A244.B7B42E82@nrubs
ig.org>
<410A42A1.926C53EA@nrubsig.org>
On Fri, 2004-07-30 at 08:44, Roland Mainz wrote:
> Matthieu Herrb wrote:
> > >>>"Things slow down (a lot) for some fonts when used as core fonts" is
> > >>>*far* better than "The build fails for almost all of our users."
> > >>>Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> > >>>pretty simple to me.
> > >>
> > >>Seconded, FWIW.
> > >
> > > So you think it's acceptable to slap the users in asia into the face or
> > > what ? Those users get a font loading performance which is *NOT*
> > > acceptable if that code gets removed again.
> >
> > I'd suggest to let imake detect the version of the installed Freetype,
> > and then disable the offending code if the installed version is too old.
>
> That's the option I'd like to avoid. Just think about it: The last
> release (="Xorg release 6.7.0") made Freetyppe 2.1.7 _mandatory_. So why
> it is a problem to make FreeType 2.1.8 mandatory (one revision newer
> than the previous release "minimum" version) for the next "major"
> release - "6.8.0". Otherwise we can really call it "Xorg release 6.7.1"
> ... =:-)
I see no problem with requiring more recent freetypes, (or other
dependencies) when there are good reasons.
I do see major problems with privately patched versions of dependencies.
Are we to start shipping libc if there are bugs? Or libm?
Good open source behavior involves good citizenship with allied
projects: I think we need to grow up and work in the larger community.
And given we have a freetype dependency, I think it behooves us to
try to work with the freetype project to detect regressions in their
library *before* it breaks us (or our users in the field). I suspect
that they'd be very happy to see such testing done in a systematic
fashion, rather than the haphazard fashion to date. (who knows, maybe
we can encourage them to run one or more tinderclients ;-)).
And breaking the build isn't a good situation. I know we've not yet
worked out policy around broken builds (now that we can detect them); on
many projects, on at least the core development platforms, if the build
is broken, no further check-ins are even permitted, and I suspect such a
policy might serve us well. But to do this, we have to work out what
our version dependencies are.
>
> > BTW, another problem seem to be that mozilla (and thunderbird) builds
> > fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
> > and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
> > known workaround for that?
>
> Not really. Someone wrote patches but they only work with FreeType
> 2.1.8. That's why I start to like the idea with linking the library
> statically into the font code, otherwise the next FreeType2 release may
> cause headache again...
Here lies madness. So in parts of the world that the Apple hinting
patent does not apply, users are supposed to rebuild X? (not to mention
other bugs that may only be discovered later being un-fixable).
Statically linking private copies just delays the pain, and makes it
harder to fix.
- Jim
Date: Fri Jul 30 07:38:02 2004
Monitoring hotplug does two thing:
1) if you pull the active VGA card with VGAcon on it, it will let the
kernel switch to another VGA device.
2) it tracks the list of available devices.
> take vga routing to card {n} and lock (blocking)
This action has an implicit - make sure you only have one card enabled
in it. So when you routed to a card I also looped over routing to every
VGA card in the system and sending it commands to make sure it is off.
That was to help protect against things like reset or user space apps
enabling secondary cards.
It's easy enough to generate the list of VGA devices in the system from
the kernel PCI structures. So the only real need for hotplug would be
to move the console if the the active VGA device were pulled.
> On Gwe, 2004-07-30 at 02:09, Jon Smirl wrote:
> > 1) disable all VGA devices for sure.
> > 2) enable a VGA device and make sure none of the other ones are
> > enabled.
> > 3) maybe list all VGA devices, but you can do this via sysfs and
> the
> > pci space.
> > 4) which device is the currently active device
> > 5) monitor hotplug for new VGA devices or removal of one
> > 6) anything else?
>
> I wasn't planning to put the hotplug part into the kernel vga switch
> code, but that does belong in the frame buffer. The implementation
> I anticipated was essentially
>
> take vga routing to card {n} and lock (blocking)
> take vga routing to card {n} and lock (nonblocking)
> free vga routing lock
>
> with multiple people being able to take the lock at once for the same
> card and automatically losing the lock on file close/program exit.
> The
> API also has to be available to the kernel.
>
>
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Date: Fri Jul 30 07:49:07 2004
In-Reply-To: <410a26ae.174.0@utvinternet.com>
--- Alastair McKinstry <mckinstry@computer.org> wrote:
> Is there any docs on the current work on this, or OLS
> discussions?
The big email described the design which was based on emails starting
in February and OLS discussions. I'm still working on getting feedback
to nail down to loose end. Feel free to contribute to the design or
code if you want.
The basic idea is that we need to put and end to having three device
drivers trying to control the video hardware: fb, X, DRI. While we're
fixing that we want to add a few things to make the system better.
>
> Regards
> Alastair McKinstry
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
Date: Fri Jul 30 07:52:50 2004
In-Reply-To: <410A3FC9.9050905@laas.fr>
<a728f9f9040729164566255ff@mail.gmail.com> <4109A244.B7B42E82@nrubs
ig.org>
On Fri, 2004-07-30 at 05:32, Matthieu Herrb wrote:
> Roland Mainz wrote:
> > Michel D?nzer wrote:
> >
> >>On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
> >>
> >>>"Things slow down (a lot) for some fonts when used as core fonts" is
> >>>*far* better than "The build fails for almost all of our users."
> >>>Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> >>>pretty simple to me.
> >>
> >>Seconded, FWIW.
> >
> >
> >
>
> I'd suggest to let imake detect the version of the installed Freetype,
> and then disable the offending code if the installed version is too old.
>
> BTW, another problem seem to be that mozilla (and thunderbird) builds
> fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
> and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
> known workaround for that?
The best part is that imake doesn't even need to do anything -- freetype
provides macros for the version, so you could check it in the code
itself. The diff would be like 10 lines I'm guessing.
--
Date: Fri Jul 30 07:54:47 2004
In-Reply-To: Jim.Gettys@hp.com wrote on Friday, 30 July 2004 at 09:04:00 -0400
<1091184967.24948.182.camel@localhost>
<1091192640.8344.20.camel@linux.site>
Jim,
I don't understand what you are trying to get at.
The required patch is already part of freetype 2.1.8. We include
plain freetype 2.1.8 for convenience. Not any patched version.
Any shared freetype lib *newer* than 2.1.7 will also work.
Chisato had convinced the freetype folks to include his patch
in 2.1.8 so he did exactly what you suggested below.
The build only breaks when one has a version of freetype installed
that is *older* than 2.1.8. Like the build of 6.7 broke if one had
a version of freetype installed that was older than 2.1.7.
Chisato was following exactly the guidelines that he was given -
pretty much the ones that you outlined below.
Now people suggest to change the rules on him because they don't
care for his patch and the requirement for FreeType 2.1.8 imposes
an inconvenience for them.
Now is this good citizenship?
Egbert.
Jim Gettys writes:
>
> I see no problem with requiring more recent freetypes, (or other
> dependencies) when there are good reasons.
>
> I do see major problems with privately patched versions of dependencies.
> Are we to start shipping libc if there are bugs? Or libm?
>
> Good open source behavior involves good citizenship with allied
> projects: I think we need to grow up and work in the larger community.
>
> And given we have a freetype dependency, I think it behooves us to
> try to work with the freetype project to detect regressions in their
> library *before* it breaks us (or our users in the field). I suspect
> that they'd be very happy to see such testing done in a systematic
> fashion, rather than the haphazard fashion to date. (who knows, maybe
> we can encourage them to run one or more tinderclients ;-)).
>
> And breaking the build isn't a good situation. I know we've not yet
> worked out policy around broken builds (now that we can detect them); on
> many projects, on at least the core development platforms, if the build
> is broken, no further check-ins are even permitted, and I suspect such a
> policy might serve us well. But to do this, we have to work out what
> our version dependencies are.
>
> >
> > > BTW, another problem seem to be that mozilla (and thunderbird) builds
> > > fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
> > > and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
> > > known workaround for that?
> >
> > Not really. Someone wrote patches but they only work with FreeType
> > 2.1.8. That's why I start to like the idea with linking the library
> > statically into the font code, otherwise the next FreeType2 release may
> > cause headache again...
>
> Here lies madness. So in parts of the world that the Apple hinting
> patent does not apply, users are supposed to rebuild X? (not to mention
> other bugs that may only be discovered later being un-fixable).
> Statically linking private copies just delays the pain, and makes it
> harder to fix.
Date: Fri Jul 30 07:58:00 2004
<410A42A1.926C53EA@nrubsig.org> <1091192640.8344.20.camel@linux.site>
<16650.24805.28354.678678@xf11.fra.suse.de>
The citizenship thing is to work with freetype to help avoid the
situation coming up in the future to bite us (and others) again.
If we don't get our act together about testing, and testing with
our upstream partners (in this case, freetype), we'll suffer again,
and again, and again...
I'm happy with whatever people think is the right solution.
- Jim
On Fri, 2004-07-30 at 10:53, Egbert Eich wrote:
> Jim,
>
> I don't understand what you are trying to get at.
> The required patch is already part of freetype 2.1.8. We include
> plain freetype 2.1.8 for convenience. Not any patched version.
> Any shared freetype lib *newer* than 2.1.7 will also work.
>
> Chisato had convinced the freetype folks to include his patch
> in 2.1.8 so he did exactly what you suggested below.
>
> The build only breaks when one has a version of freetype installed
> that is *older* than 2.1.8. Like the build of 6.7 broke if one had
> a version of freetype installed that was older than 2.1.7.
>
> Chisato was following exactly the guidelines that he was given -
> pretty much the ones that you outlined below.
> Now people suggest to change the rules on him because they don't
> care for his patch and the requirement for FreeType 2.1.8 imposes
> an inconvenience for them.
> Now is this good citizenship?
>
> Egbert.
>
>
> Jim Gettys writes:
> >
> > I see no problem with requiring more recent freetypes, (or other
> > dependencies) when there are good reasons.
> >
> > I do see major problems with privately patched versions of dependencies.
> > Are we to start shipping libc if there are bugs? Or libm?
> >
> > Good open source behavior involves good citizenship with allied
> > projects: I think we need to grow up and work in the larger community.
> >
> > And given we have a freetype dependency, I think it behooves us to
> > try to work with the freetype project to detect regressions in their
> > library *before* it breaks us (or our users in the field). I suspect
> > that they'd be very happy to see such testing done in a systematic
> > fashion, rather than the haphazard fashion to date. (who knows, maybe
> > we can encourage them to run one or more tinderclients ;-)).
> >
> > And breaking the build isn't a good situation. I know we've not yet
> > worked out policy around broken builds (now that we can detect them); on
> > many projects, on at least the core development platforms, if the build
> > is broken, no further check-ins are even permitted, and I suspect such a
> > policy might serve us well. But to do this, we have to work out what
> > our version dependencies are.
> >
> > >
> > > > BTW, another problem seem to be that mozilla (and thunderbird) builds
> > > > fails against Freetype 2.1.9. I've seen that both using OpenBSD's ports
> > > > and gentoo's portage of mozilla 1.7.1 and thunderbird 0.7. Is there a
> > > > known workaround for that?
> > >
> > > Not really. Someone wrote patches but they only work with FreeType
> > > 2.1.8. That's why I start to like the idea with linking the library
> > > statically into the font code, otherwise the next FreeType2 release may
> > > cause headache again...
> >
> > Here lies madness. So in parts of the world that the Apple hinting
> > patent does not apply, users are supposed to rebuild X? (not to mention
> > other bugs that may only be discovered later being un-fixable).
> > Statically linking private copies just delays the pain, and makes it
> > harder to fix.
> _______________________________________________
> xorg mailing list
Date: Fri Jul 30 07:58:17 2004
In-Reply-To: <410A2B42.F8C0583F@nrubsig.org>
> Michel D?nzer wrote:
> >
> > On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
> > >
> > > "Things slow down (a lot) for some fonts when used as core fonts" is
> > > *far* better than "The build fails for almost all of our users."
> > > Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> > > pretty simple to me.
> >
> > Seconded, FWIW.
>
No. We tell them that sorry, the previous code mistakenly used private
interfaces for an optimization, and we had to stop. If they want to use
the optimization, simply update their system freetype to 2.1.8 and
recompile and bam, everything works. Remember, that's what you're
telling every single user to do as is, only most of them don't even get
an optimization out of the deal.
--
Date: Fri Jul 30 08:10:26 2004
In-Reply-To: <410A42A1.926C53EA@nrubsig.org>
References: <4109A244.B7B42E82@nrubsig.org> <1091155653.888.3.camel@leguin>
<1091184967.24948.182.camel@localhost>
On Fri, Jul 30, 2004 at 02:44:17PM +0200, Roland Mainz wrote:
> Not really. Someone wrote patches but they only work with FreeType
> 2.1.8. That's why I start to like the idea with linking the library
> statically into the font code, otherwise the next FreeType2 release may
> cause headache again...
That's the idea that comes absolute last on my list by preference.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/dd3c642d/attach
ment.pgp
Date: Fri Jul 30 10:00:08 2004
<16650.2376.295504.398060@xf11.fra.suse.de>
Message-ID: <E1Bqaja-0002dl-BI@evo.keithp.com>
> People still using an older version are not expected to update to
> a version higher than 2.1.8 later if they are not willing to update
> to 2.1.8 now.
Correct. Those people may see limits in what the X distribution can do
with the older version of FreeType.
> For these the internally shipped version 2.1.8 would
> give them the opportunity to use newer code than what they already
> have.
For people with 2.1.9, the standard settings will cause them to use older
code than they already have.
> it is appropriate to ask Chisato to #ifdef his code on the version of
> FreeType however I feel it is not fair to threaten with the deletion
> of his code.
We've discussed CVS policy several times in the last months. One of the
the ideas was that code which breaks the build on 'most' platforms would
need to be fixed or get backed out until it's ready for distribution.
We also agreed that the person who applied the patch would be responsible
for fixing things to match the communities goals. I would never
unilateraly revert anyones changes against their wishes, but I would
rather have support for currently shipping versions of FreeType than this
new functionality.
My goal is to have a working build in as many "reasonable" environments as
possible. Some of those "reasonable" environments would be current
releases of the major Linux platforms. Right now, that's broken and must
be fixed.
We have two ways of fixing it -- provide our own version of FreeType or
allow our code to use older versions.
Forcing people to upgrade to our version of a vendor provided library that
we aren't responsible for is irresponsible. Those people will be left
unable to take advantage of vendor-provided security and stability fixes in
those libraries.
Our default build should use as much of the system-provided functionality
as possible; if that limits the flexibility or performance of some parts
of the system, that's OK. It's far better to accept those limits than to
accidentally cause major headaches by having multiple versions of the same
library on a machine.
I think the changes needed to work with older versions of FreeType are
minimal, let's get those into the tree so we can support as many
environments as possible.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/a432d532/attach
ment.pgp
Date: Fri Jul 30 10:05:41 2004
Message-ID: <E1Bqaow-0002eF-3i@evo.keithp.com>
No, we think it's acceptable to let users build the system in a variety of
environments, especially environments which are prevalent in the
environment today.
People stuck with core-font based applications in asian environments would
be encouraged to either switch to FreeType 2.1.8 or use our included
version. The only question is whether we should *allow* people with older
versions of FreeType to build the system the old way.
By your argument, we should be shipping custom C libraries and a custom
operating system kernel so everyone would have the benefits of the "right"
versions of those as well.
A one-size-fits-all solution is not acceptable here; people have a variety
of reasons for using various verisons of libraries, our job is to make
sure our code runs in most "reasonable" environments.
This problem doesn't seem hard to fix. Let's just get it done and move on.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/6515dd31/attach
ment.pgp
Date: Fri Jul 30 10:07:54 2004
Message-ID: <E1Bqar4-0002ej-Hu@evo.keithp.com>
> That's the option I'd like to avoid. Just think about it: The last
> release (="Xorg release 6.7.0") made Freetyppe 2.1.7 _mandatory_.
That wasn't optimal; but we were pressed for time. And, FreeType 2.1.7
was then available in most "reasonable" environments. This time, FreeType
2.1.8 *isn't* available on most systems.
Past mistakes don't justify the current behaviour.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/eb820e31/attach
ment.pgp
Date: Fri Jul 30 10:15:56 2004
<16650.24805.28354.678678@xf11.fra.suse.de>
Message-ID: <E1Bqayv-0002f7-Tj@evo.keithp.com>
> Chisato was following exactly the guidelines that he was given - pretty
> much the ones that you outlined below. Now people suggest to change the
> rules on him because they don't care for his patch and the requirement for
> FreeType 2.1.8 imposes an inconvenience for them.
We certainly want the changes that Chisato has provided to be included in
this release, but we also want to encourage people to use system provided
libraries where possible.
Those two are in conflict here.
I'm more concerned about the system security and stability implications
with having unmanaged versions of the FreeType libraries sitting around on
peoples machines than with making sure every possible new feature of our
system is provided to them.
Therefore, we should strongly encourage system vendors to provide versions
of FreeType sufficient to support the new functionality, and we should
even encourage people downloading X from CVS to use the new libraries, but
we should not force people to upgrade against their better judgement.
That 6.7.0 required 2.1.7 was unfortunate; we had significant time
pressure. However, 2.1.7 *was* distributed with current Linux versions,
so most people didn't have any trouble with that dependency.
We have an opportunity to avoid that same problem with this release; a
minor change to the code will fall back to the old behaviour for people
insistent on using older FreeType libraries.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/09e967cc/attach
ment.pgp
Date: Fri Jul 30 10:58:32 2004
<410A2B42.F8C0583F@nrubsig.org> <1091199480.906.6.camel@leguin>
Message-ID: <410A8C1E.DF74B856@nrubsig.org>
Eric Anholt wrote:
>
> On Fri, 2004-07-30 at 04:04, Roland Mainz wrote:
> > Michel D?nzer wrote:
> > >
> > > On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
> > > >
> > > > "Things slow down (a lot) for some fonts when used as core fonts" is
> > > > *far* better than "The build fails for almost all of our users."
> > > > Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> > > > pretty simple to me.
> > >
> > > Seconded, FWIW.
> >
>
> No. We tell them that sorry, the previous code mistakenly used private
> interfaces for an optimization, and we had to stop.
There was no "WE". There was only ONE person who started the rants. The
same person who started this thread again... again less than 24h before
the freeze.
Keith Packard: Why are _you_ always coming up with such kind of
"problems" in the last minute ?
> If they want to use
> the optimization, simply update their system freetype to 2.1.8 and
> recompile and bam, everything works. Remember, that's what you're
> telling every single user to do as is, only most of them don't even get
> an optimization out of the deal.
Hint: The last X release made FreeType>= 2.1.7 mandatory, later it was
updated to V2.1.8 due lots of problems in 2.1.7 AND the issue with the
CJKV optimisation. So the vendors have two choices:
1. Using a buggy FreeType 2.1.7
OR
2. Use FreeType 2.1.8
The 2nd option would trouble users much less...
----
Bye,
Roland
--
__ . . __
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
Date: Fri Jul 30 11:03:13 2004
<410A8C1E.DF74B856@nrubsig.org>
Message-ID: <E1BqbiF-0002jy-Ou@evo.keithp.com>
> 1. Using a buggy FreeType 2.1.7
> OR
> 2. Use FreeType 2.1.8
>
> The 2nd option would trouble users much less...
I agree it would be nice if everyone would just use 2.1.8, but I don't
think we should insist on that. Again, the changes necessary to use 2.1.7
or earlier appear simple, so we should just do it.
It seems far friendlier to accept what software people have than to
force our own agenda on them.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/8c68de2e/attach
ment.pgp
Date: Fri Jul 30 11:03:49 2004
Message-ID: <E1BqbjI-0002kI-Ci@evo.keithp.com>
> There was no "WE". There was only ONE person who started the rants. The
> same person who started this thread again... again less than 24h before
> the freeze.
The 'freeze' is functional only. None of this discussion relates to a
functional issue so we have time to resolve the problem before the code
freeze.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/f5e240cc/attach
ment.pgp
Date: Fri Jul 30 11:11:52 2004
In-Reply-To: <410A8C1E.DF74B856@nrubsig.org>
References: <4109A244.B7B42E82@nrubsig.org> <1091155653.888.3.camel@leguin>
<1091184967.24948.182.camel@localhost>
Message-ID: <20040730181148.GU25118@fooishbar.org>
On Fri, Jul 30, 2004 at 07:57:50PM +0200, Roland Mainz wrote:
> the freeze.
> Keith Packard: Why are _you_ always coming up with such kind of
> "problems" in the last minute ?
The FreeType thing is a problem, and it only occurred, as you say, in
the last minute. It's a problem which needs to be resolved.
> > If they want to use
> > the optimization, simply update their system freetype to 2.1.8 and
> > recompile and bam, everything works. Remember, that's what you're
> > telling every single user to do as is, only most of them don't even get
> > an optimization out of the deal.
>
> Hint: The last X release made FreeType>= 2.1.7 mandatory, later it was
> updated to V2.1.8 due lots of problems in 2.1.7 AND the issue with the
> CJKV optimisation. So the vendors have two choices:
> OR
>
So we'll leave everyone who doesn't run around updating their external
modules every single X release in the cold. Yeah, that's great.
If you're all for that, I suggest we remove support for core font
rendering altogether, as well as such legacy crap as Xprint and vga.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/c2da4645/attach
ment-0001.pgp
Date: Fri Jul 30 11:15:53 2004
In-Reply-To: <410A8C1E.DF74B856@nrubsig.org>
> >
> > On Fri, 2004-07-30 at 04:04, Roland Mainz wrote:
> > > Michel D?nzer wrote:
> > > >
> > > > On Thu, 2004-07-29 at 20:49 -0700, Eric Anholt wrote:
> > > > >
> > > > > "Things slow down (a lot) for some fonts when used as core fonts" is
> > > > > *far* better than "The build fails for almost all of our users."
> > > > > Simply saying, "Use 2.1.8 if you want fast CJKV core fonts" seems
> > > > > pretty simple to me.
> > > >
> > > > Seconded, FWIW.
> > >
> > > So you think it's acceptable to slap the users in asia into the face or
> > > what ? Those users get a font loading performance which is *NOT*
> > > acceptable if that code gets removed again.
> >
> > No. We tell them that sorry, the previous code mistakenly used private
> > interfaces for an optimization, and we had to stop.
>
> the freeze.
> Keith Packard: Why are _you_ always coming up with such kind of
> "problems" in the last minute ?
No, I was bringing this issue up again, as can be seen in the bugzilla
entry you're watching or the mailing lists between when this issue was
discussed way back when and when Keith piped up now.
The build is still broken. We shouldn't be breaking the build on
basically every linux release out there for the sake of an
optimization. We shouldn't back that optimization out, obviously, but
unless the submitter or committer of the optimization can fix it, people
without the ability to test whether their fixes break the optimization
are pretty screwed.
Note, "We" means X.Org in that sentence, obviously.
> > If they want to use
> > the optimization, simply update their system freetype to 2.1.8 and
> > recompile and bam, everything works. Remember, that's what you're
> > telling every single user to do as is, only most of them don't even get
> > an optimization out of the deal.
>
> Hint: The last X release made FreeType>= 2.1.7 mandatory, later it was
> updated to V2.1.8 due lots of problems in 2.1.7 AND the issue with the
> CJKV optimisation. So the vendors have two choices:
> OR
>
That's interesting, our maintainer is not updating FreeType to 2.1.8+
because of rendering degredations he says he's seen with it. I'm trying
to clarify what exactly those were now. If the font issues I'm seeing
now that my distribution's freetype has been blown away by X.Org (since
I'm forced to in order to do work on X.Org now) are because of the
Freetype update, then it's pretty spectacular. I'm sure hoping it
isn't, though.
--
Date: Fri Jul 30 11:47:59 2004
Subject: [Xorg] InputOnly Window as top-level window
Message-ID: <E1BqcQ8-0000vI-00@mailgate.rz.uni-karlsruhe.de>
I wonder if there an application uses InputOnly window as top-level window
(but not the main top-level window) may be with "override redirect" set to
"TRUE", or InputOnly only used as sub window!
Amir Bukhari
Date: Fri Jul 30 12:59:10 2004
References: <410A42A1.926C53EA@nrubsig.org> <E1Bqar4-0002ej-Hu@evo.keithp.com>
>
>
> > That's the option I'd like to avoid. Just think about it: The last
> > release (="Xorg release 6.7.0") made Freetyppe 2.1.7 _mandatory_.
>
> That wasn't optimal; but we were pressed for time. And, FreeType 2.1.7
I'm glad that you say this.
> was then available in most "reasonable" environments. This time, FreeType
> 2.1.8 *isn't* available on most systems.
I have a different recollection. At least my company was shipping
2.1.7 after the X.Org release came out.
>
> Past mistakes don't justify the current behaviour.
>
OK, can I take your word on this next time you provide an update
that requires code that is not widely deployed ;-)
Egbert.
Date: Fri Jul 30 13:44:35 2004
<16650.42846.746016.823955@xf11.fra.suse.de>
Message-ID: <E1BqeEp-0002r9-7o@evo.keithp.com>
> I remember discussing CVS policies however I don't remember that this
> has ever been a major issue in these discussions. You may see it as
> a corollary of what was discussed.
We certainly haven't come up with a completely concrete CVS policy yet.
It's nice to see minor issues like this one that we can use as examples of
how such a policy should work. Instead of letting problems fester for a
week or more, it would be nice to see them addressed promptly and
decisively so that each user won't have to learn about the 'official
workaround'.
> Instead I remember that people felt the fact that 2.1.7 was not widely
> deployed should not stop us from shipping as people felt the new features
> of the application that required 2.1.7 (I think it was Xft) are badly
> needed. There was no talk of making this code backward compatible.
The problem with 2.1.7 was that it was not ABI compatible with 2.1.6, so
code compiled against 2.1.6 would run incorrectly against 2.1.7, and code
compiled against 2.1.7 would not run at all against 2.1.6.
I don't know if this was completely clear during the 6.7.0 discussions
though; the precise nature of the problem is complicated.
> I just don't like to see unequal treatment of groups that are not as vocal
> here as you and me and thus easily get ignored.
Yes, we need to respect the needs of all of our users and make informed
decisions about what the software does. That's why we should work hard to
get this feature into the release for that group of people still stuck with
core-font based applications.
Getting a patch into the code which supports FreeType 2.1.7 seems like a
practical and non-discriminatory plan.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/d8df4870/attach
ment.pgp
Date: Fri Jul 30 13:57:08 2004
<16650.43069.354192.53013@xf11.fra.suse.de>
Message-ID: <E1BqeR3-0002sp-42@evo.keithp.com>
> > Past mistakes don't justify the current behaviour.
> >
>
> OK, can I take your word on this next time you provide an update
> that requires code that is not widely deployed ;-)
Sure; I do try to learn from my mistakes. Fontconfig no longer requires
specific versions of FreeType, although it (like Xft) cannot manage the
2.1.6/2.1.7 transition in a binary compatible fashion...
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/d66ba3dd/attach
ment.pgp
Date: Fri Jul 30 14:00:07 2004
In-Reply-To: <E1BqeR3-0002sp-42@evo.keithp.com>
<E1BqeR3-0002sp-42@evo.keithp.com>
Message-ID: <20040730210005.GB25118@fooishbar.org>
On Fri, Jul 30, 2004 at 01:57:01PM -0700, Keith Packard wrote:
> > > Past mistakes don't justify the current behaviour.
> >
> > OK, can I take your word on this next time you provide an update
> > that requires code that is not widely deployed ;-)
>
> Sure; I do try to learn from my mistakes. Fontconfig no longer requires
> specific versions of FreeType, although it (like Xft) cannot manage the
> 2.1.6/2.1.7 transition in a binary compatible fashion...
2.1.6->2.1.7 was, unfortunately, a major version bump disguised in a
point release.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/5a361b1e/attach
ment.pgp
From Stuart.Kreitman at Sun.COM Fri Jul 30 14:04:50 2004
Date: Fri Jul 30 14:05:37 2004
In-Reply-To: <20040730210005.GB25118@fooishbar.org>
<20040730210005.GB25118@fooishbar.org>
Message-ID: <410AB7F2.2090802@sun.com>
Could someone please give me a trivial way to get past this build error?
We have other fires to fight at the moment..
skk
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>xorg mailing list
>
>
Date: Fri Jul 30 14:09:11 2004
In-Reply-To: <410AB7F2.2090802@sun.com>
<20040730210005.GB25118@fooishbar.org> <410AB7F2.2090802@sun.com>
On Fri, 2004-07-30 at 14:04, Stuart Kreitman wrote:
> Could someone please give me a trivial way to get past this build error?
> We have other fires to fight at the moment..
> skk
Set
in host.def. This will result in overwriting your distribution's
freetype2, which may result in other pain.
--
Date: Fri Jul 30 14:12:33 2004
<20040730210005.GB25118@fooishbar.org>
<410AB7F2.2090802@sun.com> <1091221747.43156.15.camel@leguin>
On Fri, Jul 30, 2004 at 02:09:08PM -0700, Eric Anholt wrote:
> in host.def. This will result in overwriting your distribution's
> freetype2, which may result in other pain.
^^^
will
Every time we double up with a system library, it causes the user pain
and baby Jesus to cry once again. The only question is how much pain
we're causing, and if it's justifiable.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/0782da81/attach
ment.pgp
Date: Fri Jul 30 14:24:57 2004
Subject: [Xorg] cfk tinerbox things
Message-ID: <21b401c4767b$a17d87b0$1e01a8c0@cnt496>
1. Can someone kick the columns that start with cfk and don't have any activity?
cfk.gt.bki810
cfk.mdk.v3-Linux2.6.3
cfk.sahara.knoppix3.4
cfk.tsp.knoppix3.4
and cfk.tsp Linux 2.6.6 Clbr - I rebooted the box without ^Cing the client.
Sorry about the big names that make wide columns and then switching to small
names that use up even more columns. ;)
2. Does it really make sense for tinderbox client to rm-rf everything? at 4
hours per build, I would think that incremental updates would be more useful.
3. I think it is worth mentioning that cfk.sahara.kpx3.4 (green) is a
knoppix3.4 CD boot, with just #define HasFreetype2 NO - so pretty easy to get a
box up and testing.
Carl K
http://www.personnelware.com/carl/resume.html
Date: Fri Jul 30 14:25:18 2004
In-Reply-To: <20040730211231.GC25118@fooishbar.org>
<20040730210005.GB25118@fooishbar.org>
<20040730211231.GC25118@fooishbar.org>
Message-ID: <410ABC8F.5090805@sun.com>
Daniel Stone wrote:
>On Fri, Jul 30, 2004 at 02:09:08PM -0700, Eric Anholt wrote:
>
>
>>in host.def. This will result in overwriting your distribution's
>>freetype2, which may result in other pain.
>>
>>
> ^^^
> will
>
>Every time we double up with a system library, it causes the user pain
>and baby Jesus to cry once again. The only question is how much pain
>we're causing, and if it's justifiable.
>
I'm on the verge of asking to slip tonight's freeze deadline untill this
issue is resolved.
skk
Date: Fri Jul 30 14:33:55 2004
In-Reply-To: <410ABC8F.5090805@sun.com>
<20040730210005.GB25118@fooishbar.org>
<20040730211231.GC25118@fooishbar.org> <410ABC8F.5090805@sun.com>
On Fri, Jul 30, 2004 at 02:24:31PM -0700, Stuart Kreitman wrote:
> I'm on the verge of asking to slip tonight's freeze deadline untill this
> issue is resolved.
Tonight is a feature freeze, not a code freeze.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/aeb8ecbc/attach
ment.pgp
Date: Fri Jul 30 14:37:16 2004
Subject: [Xorg] New XAA Render hooks
http://www.freedesktop.org/~anholt/xorg-renderhooks.diff
Here's a patch for the new Render hooks and support for them on Radeon.
More information is in the ChangeLog diff at the top. Note that this
causes all other render accelerations using XAA to become disabled until
those drivers get fixed.
I really want to see us have the cleanest Render support we can in this
release, which is why I'm disabling old support even though it might
seem to "just work" for others currently. I know we've got some
outstanding issues in software fallbacks, unfortunately.
This extends the XAAInfoRec. What's the proper way for dealing with
extending that, in terms of module ABI?
--
Date: Fri Jul 30 14:45:09 2004
In-Reply-To: <20040730213353.GD25118@fooishbar.org>
<20040730210005.GB25118@fooishbar.org>
<20040730213353.GD25118@fooishbar.org>
On Sat, Jul 31, 2004 at 07:33:53AM +1000, Daniel Stone wrote:
> On Fri, Jul 30, 2004 at 02:24:31PM -0700, Stuart Kreitman wrote:
> > I'm on the verge of asking to slip tonight's freeze deadline untill this
> > issue is resolved.
>
> Tonight is a feature freeze, not a code freeze.
Yes, but Stuart, Deron, Eric and Keith are working together to merge in
Composite, which is a feature.
Please resolve this build issue so that their work is not held up. We
can resolve the remaining issues surrounding FreeType2 next week.
Date: Fri Jul 30 14:45:14 2004
On Fri, 2004-07-30 at 14:37 -0700, Eric Anholt wrote:
> http://www.freedesktop.org/~anholt/xorg-renderhooks.diff
>
> Here's a patch for the new Render hooks and support for them on Radeon.
> More information is in the ChangeLog diff at the top.
The names of the new functions could be better? :P
> This extends the XAAInfoRec. What's the proper way for dealing with
> extending that, in terms of module ABI?
Bump the minor version of the xaa module, and check it in the drivers.
The radeon driver already has code for the last such change.
--
Date: Fri Jul 30 14:50:35 2004
In-Reply-To: <20040730214504.GA9503@kem.org>
<20040730210005.GB25118@fooishbar.org>
<20040730213353.GD25118@fooishbar.org>
<20040730214504.GA9503@kem.org>
On Fri, Jul 30, 2004 at 05:45:04PM -0400, Kevin E Martin wrote:
> On Sat, Jul 31, 2004 at 07:33:53AM +1000, Daniel Stone wrote:
> > On Fri, Jul 30, 2004 at 02:24:31PM -0700, Stuart Kreitman wrote:
> > > I'm on the verge of asking to slip tonight's freeze deadline untill this
> > > issue is resolved.
> >
> > Tonight is a feature freeze, not a code freeze.
>
> Yes, but Stuart, Deron, Eric and Keith are working together to merge in
> Composite, which is a feature.
>
> Please resolve this build issue so that their work is not held up. We
> can resolve the remaining issues surrounding FreeType2 next week.
Sorry, I didn't quite make the connection.
Run with HasFreetype2 NO (or whatever the symbol is for now), but as an
upstream and a distributor, I don't consider this a solution. It's a
hack.
:) d
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/f2b0598e/attach
ment.pgp
Date: Fri Jul 30 15:09:09 2004
<410ABC8F.5090805@sun.com>
Message-ID: <E1BqfYe-0002vD-L0@evo.keithp.com>
Around 14 o'clock on Jul 30, Stuart Kreitman wrote:
> I'm on the verge of asking to slip tonight's freeze deadline untill this
> issue is resolved.
It's not a functional issue really; just a bug in the code which causes it
to not compile against FreeType 2.1.7. I think it's easy to fix, but I
don't feel comfortable fixing it myself (or I already would have).
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/025a1aa2/attach
ment.pgp
Date: Fri Jul 30 15:11:35 2004
<1090860442.886.5.camel@leguin>
Message-ID: <229901c47682$24ae5f50$1e01a8c0@cnt496>
> On Mon, 2004-07-26 at 09:35, Matthieu Herrb wrote:
> > Carl Karsten wrote:
> > > Where can I see the tinderbox statuses? (1 remote web page would be
better than
> > > me checking 3 or 4 local boxes.)
> > >
> > > Is there any provision for a local cache? Like squid, rsync or anything
so that
> > > my set of boxes only has to hit the source once? Not that I care about my
> > > bandwidth, but if a bunch of sites all have multiple boxes, it adds up.
> >
> > Yes, it would be nice to be able to get a local copy of the xorg
> > repository through CVsup or cvsync (<http://www.cvsync.org/>).
> >
> > I don't know if one of these are available on pdx.
>
> Yep, cvsup is set up. Here's my fd-supfile:
>
> *default host=pdx.freedesktop.org
> *default base=/usr/local/etc/cvsup/fdsup
> *default prefix=/home/ncvs/freedesktop
> *default release=cvs
> *default delete use-rel-suffix
> *default compress
>
> xlibs
> xserver
> xapps
> mesa
> xorg
>
Um, I need some spoon feeding. I have squid running on my firewall. I can
install about anything on the mandrake and knoppix boxes.
Carl K
Date: Fri Jul 30 15:45:07 2004
Subject: [Xorg] Re: mga driver doesn't build
References: <410ABF01.2020507@sun.com> <200407301803.23113.ajax@nwnk.net>
<410ACAF6.3000206@sun.com> <200407301833.29392.ajax@nwnk.net>
Message-ID: <410ACF45.3080501@sun.com>
Adam Jackson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Friday 30 July 2004 18:25, you wrote:
>
>
>>
>>
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>On Friday 30 July 2004 17:34, you wrote:
>>>
>>>
>>>>ajax:
>>>>
>>>>I just did a clean checkout and build. It breaks in mga_driver.c Do you
>>>>have an idea what's up
>>>>with this?
>>>>
>>>>thanks,
>>>>
>>>>Stuart Kreitman
>>>>
>>>>
>>>not offhand, i've been building it continually during the dlloader work.
>>>eich just committed to it too, but only a comment, shouldn't affect
>>>anything.
>>>
>>>i'll try it again, what's the error you're seeing?
>>>
>>>
>
>damn damn damn. sun cc doesn't let you autoconvert a void * to a function
>pointer. i knew the LoaderSymbol abuse would bite me in the ass.
>
>i've attached the patch that caused the breakage, apply with patch -R for the
>moment. i'll get that cleaned up ASAP. sorry for the mess.
>
>
>
Thanks so much for the quick response, you've been very helpfull.
skk
Date: Fri Jul 30 15:47:56 2004
In-Reply-To: <20040730214504.GA9503@kem.org>
<20040730210005.GB25118@fooishbar.org>
<20040730213353.GD25118@fooishbar.org> <20040730214504.GA9503@kem.org>
Message-ID: <410ACFEC.6090805@sun.com>
>On Sat, Jul 31, 2004 at 07:33:53AM +1000, Daniel Stone wrote:
>
>
>>On Fri, Jul 30, 2004 at 02:24:31PM -0700, Stuart Kreitman wrote:
>>
>>
>>>I'm on the verge of asking to slip tonight's freeze deadline untill this
>>>issue is resolved.
>>>
>>>
>>Tonight is a feature freeze, not a code freeze.
>>
>>
>
>Yes, but Stuart, Deron, Eric and Keith are working together to merge in
>Composite, which is a feature.
>
>Please resolve this build issue so that their work is not held up. We
>can resolve the remaining issues surrounding FreeType2 next week.
>
It looks like we have an agreement that Eric will make the commits today
and Deron
will follow up with the LG ifdefs next week.
skk
From Deron.Johnson at Sun.COM Fri Jul 30 16:06:11 2004
From: Deron.Johnson at Sun.COM (Deron Johnson)
Date: Fri Jul 30 16:06:15 2004
In-Reply-To: <410ACFEC.6090805@sun.com>
<20040730210005.GB25118@fooishbar.org>
<20040730213353.GD25118@fooishbar.org> <20040730214504.GA9503@kem.org>
<410ACFEC.6090805@sun.com>
Message-ID: <410AD463.4020707@Sun.COM>
> It looks like we have an agreement that Eric will make the commits today
> and Deron
> will follow up with the LG ifdefs next week.
Actually, what Eric and I agreed is that he will integrate the composite
code from the modular tree and his composite wrapper layer. When I get
back from vacation next week (on Friday) I will add any additional bug
fixes that are necessary and I will review Eric's wrapper layer and
possibly make suggestions for improvement.
The LG #ifdefs (now called the LG3D ifdefs) are a completely separate
topic. I would still like permission to integrate them. They are very
low risk, as I am the only one who compiles with this symbol defined.
And there is establish precedent for something like this (viz. #ifdef
DARWIN).
From Alexander.Gottwald at s1999.tu-chemnitz.de Fri Jul 30 17:59:17 2004
Date: Fri Jul 30 18:15:40 2004
Subject: [Xorg] Re: CVS Update: xc (branch: trunk)
In-Reply-To: <20040730210020.C6B829F7C0@freedesktop.org>
References: <20040730210020.C6B829F7C0@freedesktop.org>
Egbert Eich wrote:
> Log message:
> 2004-07-30 Egbert Eich <eich@freedesktop.org>
>
> * lib/xtrans/Xtransutil.c: (trans_mkdir):
> fail hard if socket directories cannot be chowned to root or
> chmod'ed to the requested mode if 'sticky' bit is requested for
> this directory instead of just print a warning that will remain
> unnoticed most of the times.
What about systems like windows which have no user root? Is it okay to keep
the old behaviour for cygwin?
bye
ago
NP: Lacrimosa - Der Morgen danach
--
Date: Fri Jul 30 18:18:07 2004
<1091223888.32409.51.camel@localhost>
On Fri, 2004-07-30 at 14:44, Michel D?nzer wrote:
> On Fri, 2004-07-30 at 14:37 -0700, Eric Anholt wrote:
> > http://www.freedesktop.org/~anholt/xorg-renderhooks.diff
> >
> > Here's a patch for the new Render hooks and support for them on Radeon.
> > More information is in the ChangeLog diff at the top.
>
> The names of the new functions could be better? :P
Got any suggestions? I love to adopt other peoples' names for things.
> > This extends the XAAInfoRec. What's the proper way for dealing with
> > extending that, in terms of module ABI?
>
> Bump the minor version of the xaa module, and check it in the drivers.
> The radeon driver already has code for the last such change.
OK, thanks.
--
Date: Fri Jul 30 18:26:27 2004
Subject: [Xorg] Re: mga driver doesn't build
In-Reply-To: <410ACF45.3080501@sun.com>
References: <410ABF01.2020507@sun.com> <200407301833.29392.ajax@nwnk.net>
<410ACF45.3080501@sun.com>
Hash: SHA1
On Friday 30 July 2004 18:44, Stuart Kreitman wrote:
> Thanks so much for the quick response, you've been very helpfull.
CVS should be fixed now, let me know if it's still busted. Again, sorry for
the mess.
- - ajax
iD8DBQFBCvU8W4otUKDs0NMRAgCMAKC2qxNDbVofFjlbjtFahRi037HhVACg4/0V
VpMG605jjbtAyTEcXotwBk0=
=gA5i
Date: Fri Jul 30 18:28:16 2004
Subject: [Xorg] Re: Proposed: xlibs
Message-ID: <20040731012743.GU7318@fooishbar.org>
On Sat, Jul 31, 2004 at 09:42:00AM +1000, Daniel Stone wrote:
> I'm proposing xlibs with this mail.
>
> Rationale:
> Everyone uses and loves X. The current list of xlibs modules is:
> Extensions - CompositeExt, DamageExt, FixesExt, ResourceExt,
> PanoramiXExt, RecordExt, XCalibrateExt, ScrnSaverExt,
> XExtensions, Xproto, PM, Randr, Render
> Libraries - FS, ICE, SM, X11, XCalibrare, XRes, XTrap, Xau, Xext,
> Xcomposite, Xcursor, Xdamage, Xdmcp, Xi, Xfixes, Xfont,
> Xfontcache, Xft, Xinerama, Xmu, Xtst, Xrandr, Xrender, Xss,
> Xv, Xxf86dga, Xxf86misc, Xxf86rush, Xxf86vm, xkbfile, xkbui
> Data - xkbdesc
> Bastard half-children of the 80's - xtrans
> Half-supported libraries - Xaw, Xp, Xpm, Xt
>
> The half-supported libraries are to be considered deprecated. While they
> will be included in this platform release, and will be until such time
> as they are no longer enjoying widespread use, they are to be removed in
> later releases.
This is more difficult than it appears - there are two competing
versions of xlibs out there (modular and monolithic). Thus, I think what
we need to do here is specify that this component can also be fulfilled
by a full installation of X11R6.7 (either 6.7.0 or 6.7.1), and leave it
at that.
... but pkg-config support is pretty much essential. So we'd need to
port the pkg-config stuff back to 6.7.1 if we are to depend upon that.
X.Org guys: do I have approval to add this stuff into the tree tonight,
even if I do miss the feature freeze by an hour or two? If we can get
pkg-config support in for all the libraries, paralleling what is in the
modular tree, that would rock, and make the platform release a lot
smoother.
--
-------------- next part --------------
Name: not available
Size: 189 bytes
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/b3c57615/attach
ment.pgp
Date: Fri Jul 30 19:05:43 2004
<410ACFEC.6090805@sun.com>
Message-ID: <E1BqjFg-0002zf-JB@evo.keithp.com>
Around 15 o'clock on Jul 30, Stuart Kreitman wrote:
> It looks like we have an agreement that Eric will make the commits today
> and Deron will follow up with the LG ifdefs next week.
Great. I'll keep on track getting the Render redirection working; I think
I can have that done this evening.
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040730/25f44161/attach
ment.pgp
Date: Fri Jul 30 21:57:38 2004
Subject: [Xorg] Lot's of information on MS Longhorn graphics
If you're interested there is a lot of information about MS Longhorn
graphics here...
http://www.microsoft.com/whdc/driver/ldk/default.mspx
http://www.microsoft.com/whdc/device/display/aero/default.mspx
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
From carl at personnelware.com Sat Jul 31 07:49:08 2004
Date: Sat Jul 31 07:48:31 2004
Subject: [Xorg] libcwrapper.c build error
Message-ID: <25b001c4770d$892092b0$1e01a8c0@cnt496>
cfk.sahara.kpx3.4 Linux 2.6.6 Clbr -
knoppix3.4
731005723.log
Not really sure what the problem is. 7/30 9:30am build was ok, failed a few
different ways after that.
Carl K
Date: Sat Jul 31 08:44:44 2004
Subject: [Xorg] shared vs static libraries
Message-ID: <410BBE62.3060700@laas.fr>
Hi,
It looks like some of the new libraries are built static only. In the
past (in XFree86) this has been often seen as a problem by 3rd party
developpers who want to build application in terms of loadable (with
dlopen) modules and need functions in these libraries. This is among
others the case of KDE.
This would affect libdmx, libXprintAppUtil, libXprintutil.
--
Matthieu
From eta at lclark.edu Sat Jul 31 10:43:21 2004
Date: Sat Jul 31 10:43:25 2004
Subject: [Xorg] libcwrapper.c build error
In-Reply-To: <25b001c4770d$892092b0$1e01a8c0@cnt496>
References: <25b001c4770d$892092b0$1e01a8c0@cnt496>
On Sat, 2004-07-31 at 07:49, Carl Karsten wrote:
> cfk.sahara.kpx3.4 Linux 2.6.6 Clbr -
>
> knoppix3.4
>
> http://freedesktop.org/cgi-bin/tinderbox3/showlog.pl?machine_id=56&logfile=200
40731005723.log
>
> Not really sure what the problem is. 7/30 9:30am build was ok, failed a few
> different ways after that.
>
> Carl K
I think a few lines above where there error begins may be significant:
make[5]: warning: Clock skew detected. Your build may be incomplete.
make[5]: Leaving directory `/mnt/hda2/XMonolithic/xc/programs/Xserver/hw/dmx'gcc
-m32 -o Xorg -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wal
l -Wpointer-arith -Wundef -L../../exports/lib xkb/xf86KillSrv.o xkb/xf86VT
.o xkb/xf86Private.o ../../programs/Xserver/hw/xfree86/common/xf86
Init.o ../../programs/Xserver/hw/xfree86/common/xf86IniExt.o ../../programs/Xser
ver/hw/xfree86/common/libxf86.a ../../programs/Xserver/hw/xfree86/pa
rser/libxf86config.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_os.a .
./../programs/Xserver/hw/xfree86/loader/libloader.a ../../programs/
Xserver/hw/xfree86/common/libxf86.a dix/libdix.a os/libos.a ../../lib
/font/fontbase.o ../../lib/font/libfontbase.a Xext/libexts.a xk
b/libxkb.a Xi/libxinput.a lbx/liblbx.a ../..
/lib/lbxutil/liblbxutil.a ../../programs/Xserver/hw/xfree86/common/libxf86.a
Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a
../../lib/lbxutil/liblbxutil.a randr/librandr.a render/libre
nder.a xfixes/libxfixes.a damageext/libdamage.a miext/damage/libdamage.
a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a
lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/
librandr.a render/librender.a xfixes/libxfixes.a damageext/libdamage.a
miext/damage/libdamage.a ../../programs/Xserver/hw/xfree86/os-support/libxf86_
os.a -lz -lm -lXau -lXdmcp -rdynamic -ldl -Wl,-rpath-li
nk,../../exports/lib
make[4]: Warning: File òs/libcwrapper.c' has modification time 3.7e+04 s in the
future
gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wp
ointer-arith -Wundef -fno-merge-constants -I../.. -I../../exports/include
-Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX
_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SO
URCE -D_GNU_SOURCE -DSHAPE
-DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -D
DPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAG
E -DXEVIE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH
-DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree
86Server -DXF86VIDMODE
-DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_
ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((7)
* 100000) + ((0) * 1000) + 0)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -c
-o os/libcwrapper.o os/libcwrapper.c
os/libcwrapper.c:29:15: X.h: No such file or directory
os/libcwrapper.c:33:17: Xmd.h: No such file or directory
os/libcwrapper.c:34:17: Xos.h: No such file or directory
os/libcwrapper.c:48:24: Xfuncproto.h: No such file or directory
os/libcwrapper.c:49:16: os.h: No such file or directory
--
From carl at personnelware.com Sat Jul 31 12:37:33 2004
Date: Sat Jul 31 12:36:58 2004
Subject: [Xorg] libcwrapper.c build error -
References: <25b001c4770d$892092b0$1e01a8c0@cnt496>
<1091295801.892.8.camel@leguin>
Message-ID: <26c401c47735$d3e5eed0$1e01a8c0@cnt496>
make[5]: warning: Clock skew detected. Your build may be incomplete.
knoppix@7[hda2]$ ntpdate -q time.rose-hulman.edu
server 137.112.7.11, stratum 4, offset 89826.425941, delay 0.06856
30 Jul 14:30:13 ntpdate[24498]: step time server 137.112.7.11 offset
89826.425941 sec
Yup. thought I had them all set. Sorry about that.
knoppix@7[hda2]$ ntpdate -q time.rose-hulman.edu
server 137.112.7.11, stratum 4, offset 0.724175, delay 0.06918
31 Jul 15:32:41 ntpdate[25696]: step time server 137.112.7.11 offset 0.724175
sec
I better restart the current build.
Carl K
Date: Sat Jul 31 13:54:34 2004
Subject: [Xorg] Xevie addition to libXext
In-Reply-To: <20040731152811.B30039F71E@freedesktop.org>
References: <20040731152811.B30039F71E@freedesktop.org>
Message-ID: <410C0210.7030006@laas.fr>
> Module name: xc
> Changes by: stukreit@pdx. 04/07/31 08:28:11
>
> Log message:
> 2004-07-31 Stuart Kreitman <stuart dot kreitman at sun dot com>
>
> Integration of XEVIE branch to trunk, client side
> https://freedesktop.org/bugzilla/show_bug.cgi?id=947
> lib/Xext/Imakefile
> Added Files:
> lib/Xext/Xevie.c
>
> Modified files:
> ./:
> ChangeLog
> xc/lib/Xext/:
> Imakefile
> Added files:
> xc/lib/Xext/:
> Xevie.c
This addition requires a minor library revision number increment.
--
Matthieu
Date: Sat Jul 31 14:24:44 2004
Subject: [Xorg] Xevie addition to libXext
<410C0210.7030006@laas.fr>
Message-ID: <E1Br12n-0005Nd-6F@evo.keithp.com>
> > Added files:
> > xc/lib/Xext/:
> > Xevie.c
>
> This addition requires a minor library revision number increment.
I think it's better to have separate libraries for each extension; can we
do that in this case? What do other people think?
-keith
-------------- next part --------------
Name: not available
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040731/37b14391/attach
ment.pgp
From alexdeucher at gmail.com Sat Jul 31 22:55:41 2004
Date: Sat Jul 31 22:55:51 2004
Subject: [Xorg] Re: X.Org DRI merge and what about new dri tree.
References: <1090545103.17540.44.camel@darkstar>
<1090555440.899.15.camel@leguin>
<1090572982.1740.12.camel@rh10.fe.up.pt>
<1090601014.924.13.camel@leguin>
Message-ID: <a728f9f904073122557023e10b@mail.gmail.com>
On Fri, 23 Jul 2004 09:43:34 -0700, Eric Anholt <eta@lclark.edu> wrote:
> On Fri, 2004-07-23 at 01:56, S?rgio M. Basto wrote:
> > On Fri, 2004-07-23 at 05:04, Eric Anholt wrote:
> > > I still need to merge the development drivers
> > > (mach64, savage), but my testbox is down due to a bad floppy and I do
> > > want to test these merges on the appropriate hardware.
> >
> > yes , I had this problem yesterday, DRI savage module doesn't compile.
> > What I have to change to compile savage dri modules ?
> > or How make xorg-cvs compile savage dri modules ?
>
> Someone needs to go into x.org cvs, cd .../drivers/savage, cvs up
> -jDRI-XFree86-4_3_99_12-merge -jDRI and resolve conflicts, place the new
> code under a BuildDevelDRIDrivers ifdef, and test. Until then you won't
> be able to build a working savage setup from x.org.
FYI... I just merged the savage DDX and resolved the conflicts in my
local tree. now to build and test. BTW, it looks like the savage DRI
hasn't been merged yet.
Alex
>
> #define BuildDevelDRIDrivers YES is the host.def switch for building
> development dri drivers.
>
> --
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

Xorg Mailing List 2004 July

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Xorg Mailing List 2004 July

Uploaded by

Copyright:

Available Formats

From loc at toya.net.

pl Thu Jul 1 04:19:02 2004

You might also like