Xorg mailing list 2004 June

From dirk.westfal at frankfurter-verein.de Tue Jun 1 08:35:30 2004
From: dirk.westfal at frankfurter-verein.de (Dirk Westfal)
Date: Tue Jun 1 02:48:40 2004
Subject: [Xorg] X -configure : returns wrong results vor Hor./Vert Refresh
Rate on different monitors.
Message-ID: <[email protected]>
Hi all,
when running X -configure, the created config file has doubled HorizSync lines
and sometimes a wrong VertRefresh:
Section "Monitor"
...
HorizSync 31.5 - 48.5
HoizSync 3433123 - 0.0
VertRefresh 40.0 - 70.0
..
This happens with Monitors from Belinea, Dell end else.
Manually fixing the file works, but I need to create X configurations on the
fly.
Has somebody an idea what to to about this ?
Xserver: Release 11 December 2003
Os: FEdora Core 2
--
Dirk Westfal //Admin/RHCE/6.2//DGQ/QB
live linux cd based on fedora core 1
http://www.l4a.de/distribution/xkdegnome/walkthrough/
From carl at personnelware.com Tue Jun 1 04:35:32 2004
From: carl at personnelware.com (Carl Karsten)
Date: Tue Jun 1 04:32:03 2004
Subject: [Xorg] XvMC depandancies
Message-ID: <2c9401c447cc$8e09bd80$1e01a8c0@cnt496>
mplayer: ./configure
Checking for XvMC ... no
What do I need to use that?
Carl K
From carl at personnelware.com Tue Jun 1 08:48:52 2004
From: carl at personnelware.com (Carl Karsten)
Date: Tue Jun 1 08:45:26 2004
Subject: [Xorg] Re: [MPlayer-users] XvMC depandancies
References: <2c9401c447cc$8e09bd80$1e01a8c0@cnt496><200406011333.56991.michal@ke
rnel-panic.cjb.net><2d6501c447d4$d436da60$1e01a8c0@cnt496>
<[email protected]>
Message-ID: <2e7301c447ef$f38322f0$1e01a8c0@cnt496>
> Carl Karsten said:
> >> Checking for XvMC ... no
> Hmm, never seen x.org , so I will tell you how it works on XFree86.
> First XvMC library is splited on 2 parts. A common library that
> have only few non significant functions and device dependant
> library that is specific for the hardware. (No idea why they have
> not done it right - with automatic switching, depening on the device).
>
> So the configure scrtipt checks for XvMCNvidia (or something like that)
> that is the driver that get installed with NVidia binnary driver,
> and is the only known (by me) driver that have hardware IDCT decoding.
>
> Without it software decoding (with mmx,3dnow,sse) is faster.
>
> There is another library (i810) that comes with xfree86, but I do
> not include it as it may be present even if you don't have i810 card.
>
> The S3 ProSavige/Twister driver is currently not operational (some
> interput mess with dri, that I cannot even give it a try I don't
> have the hardware)
>
> I don't know if ATI have any xvmc software support (even by binnary drivers.
>
> i don't remember the additional switch to point xvmc library
> but it was something line --with-xvmclib=
> you can point the library name (without .a/.so) or full pathname.
>
> Wish you luck.
Thank you.
I have an i810.
# ldconfig -p |grep 810
libI810XvMC.so.1 (libc6) => /usr/X11R6/lib/libI810XvMC.so.1
libI810XvMC.so (libc6) => /usr/X11R6/lib/libI810XvMC.so
$ locate XvMC
/usr/X11R6/lib/libXvMC.so
/usr/X11R6/lib/libXvMC.so.1
/usr/X11R6/lib/libXvMC.so.1.0
/usr/X11R6/lib/libI810XvMC.so
/usr/X11R6/lib/libI810XvMC.so.1
/usr/X11R6/lib/libI810XvMC.a
/usr/X11R6/lib/libI810XvMC.so.1.0
/usr/X11R6/lib/libXvMC.a
/usr/X11R6/include/X11/extensions/XvMC.h
/usr/X11R6/include/X11/extensions/XvMCproto.h
/usr/X11R6/include/X11/extensions/XvMClib.h
I have tried every sensable permutation of --with-xvmclib
[path][/][libI810XvMC][.so]
./configure --enable-xvmc --with-xvmclib=/usr/X11R6/lib/libI810XvMC
and yet it keeps saying "...no."
My guess is if autodetect didn't detect it, something isn't right with the xorg
side.
Thank you again for your time.
Carl K
From nores at e-ticket-marketing.com Tue Jun 1 08:00:02 2004
From: nores at e-ticket-marketing.com (eTicket)
Date: Tue Jun 1 09:08:20 2004
Subject: [Xorg] It cleans and shines jewelry in seconds..Guaranteed
Message-ID: <[email protected]>
No text version was provided
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://freedesktop.org/pipermail/xorg/attachments/20040601/bf5b64a5/attachm
ent.htm
From nores at e-ticket-marketing.com Tue Jun 1 09:30:01 2004
From: nores at e-ticket-marketing.com (eTicket)
Date: Tue Jun 1 10:42:01 2004
Subject: [Xorg] It's sunglasses that gives an attitude.. Not Clothes
Message-ID: <20040601123001.pva^[email protected]>
No text version was provided
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://freedesktop.org/pipermail/xorg/attachments/20040601/10eed2f2/attachm
ent.html
From aduitsis at noc.ntua.gr Wed Jun 2 00:49:52 2004
From: aduitsis at noc.ntua.gr (Athanasios Douitsis)
Date: Wed Jun 2 00:50:27 2004
Subject: [Xorg] xserver cannot establish listening sockets
Message-ID: <[email protected]>
Hello all,
I compiled the fdo xserver from cvs but when I try
to do something like
Xvesa :1
it says that it cannot establish the listening sockets
and that I should check whether there is an X server
already running. Needless to say, there isn't :-)
This behaviour concerns the fdo xserver pulled from
last weeks cvs, older versions work out fine.
Does anybody has any idea about this?
BTW, I was wondering, will the fdo xserver eventualy become
a replacement for x.org, or will the damage and composite
extensions be incorporated in x.org and continue from there?
Many thanks in advance,
Athanasios

From komando_c at tlen.pl Wed Jun 2 03:04:11 2004
From: komando_c at tlen.pl (Cezary Marchel)
Date: Wed Jun 2 03:04:21 2004
Subject: [Xorg] multibutton mouse problem
Message-ID: <[email protected]>
Hello!
I've got a problem -I have bought a new 8-button mouse a4 swop-80, and I
can run only 2 common buttons +wheel. Could you possibly write X.org
code in such way that I could use my mouse properly?
I know that I'm not the only one with such a problem.
Unfortunately I'm not a programmer, so I can't help you much but if you
think that I could help in any way, please ask.
Best Wishes
Cezary Marchel
From elylevy-xserver at cs.huji.ac.il Wed Jun 2 03:56:21 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Jun 2 03:56:26 2004
Subject: [Xorg] bugzilla and voting
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Hey,
I wanted to suggest to enable the bug voting in bugzilla
I know it's one of those things that have long boring arguments about
but here I go anyhow;)
- It's good for the users let them take off steam instead of going to
complain to developers they know their voice is being heard.
- It gives user indication how many other people encounter that bug
- It gives developers information about which bug fixes/features are most
requested by users.
Now people would ask what if we don't care about what the users has to
say? Personaly I got the impression that this is not the case in projects
which are hosted on fd.o in general and espcialy not in the xorg
community. but even then knowing doesn't mean you have to act by it, it
still gives you information about credibility of bugs if one person submit
a bug you don't know how accurate it is, if 1000 ppl vote for it you know
there is something in it.
I don't see any downside for it, but since I saw some people object to it
I thought to explain my point of view:)
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 2 Jun 2004, Cezary Marchel wrote:
> Hello!
>
> I've got a problem -I have bought a new 8-button mouse a4 swop-80, and I
> can run only 2 common buttons +wheel. Could you possibly write X.org
> code in such way that I could use my mouse properly?
> I know that I'm not the only one with such a problem.
> Unfortunately I'm not a programmer, so I can't help you much but if you
> think that I could help in any way, please ask.
>
> Best Wishes
> Cezary Marchel
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From daniel at freedesktop.org Wed Jun 2 04:27:05 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Wed Jun 2 04:27:06 2004
Subject: [Xorg] bugzilla and voting
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Wed, Jun 02, 2004 at 01:56:21PM +0300, Ely Levy wrote:
> I wanted to suggest to enable the bug voting in bugzilla
> I know it's one of those things that have long boring arguments about
> but here I go anyhow;)
>
> - It's good for the users let them take off steam instead of going to
> complain to developers they know their voice is being heard.
> - It gives user indication how many other people encounter that bug
> - It gives developers information about which bug fixes/features are most
> requested by users.
>
> Now people would ask what if we don't care about what the users has to
> say? Personaly I got the impression that this is not the case in projects
> which are hosted on fd.o in general and espcialy not in the xorg
> community. but even then knowing doesn't mean you have to act by it, it
> still gives you information about credibility of bugs if one person submit
> a bug you don't know how accurate it is, if 1000 ppl vote for it you know
> there is something in it.
>
> I don't see any downside for it, but since I saw some people object to it
> I thought to explain my point of view:)
The problem there is when you have users vote for impossible bugs (e.g.
want open-source 3D acceleration for r3xx), and these are the most
popular bugs. Users then get upset about the lack of responsiveness of
the project; fd.o/X.Org comes off looking aloof.
--
Daniel Stone <[email protected]>
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/20040602/eea3682d/attach
ment.pgp
From caroool2003 at yahoo.com.br Wed Jun 2 09:44:46 2004
From: caroool2003 at yahoo.com.br (caroool2003)
Date: Wed Jun 2 06:14:29 2004
Subject: [Xorg] Camila
Message-ID: <[email protected]>
An HTML attachment was scrubbed...
URL: http://freedesktop.org/pipermail/xorg/attachments/20040602/413e55c6/attachm
ent.htm
From elylevy-xserver at cs.huji.ac.il Wed Jun 2 06:28:57 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Jun 2 06:29:01 2004
Subject: [Xorg] bugzilla and voting
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
>
> The problem there is when you have users vote for impossible bugs (e.g.
> want open-source 3D acceleration for r3xx), and these are the most
> popular bugs. Users then get upset about the lack of responsiveness of
> the project; fd.o/X.Org comes off looking aloof.
That's always the problem voting or not, but i see why voting would
increase it, I think its a small price for the advanteges and what's
impossible now might be possible in the future, but we can add a mark for
a bug as impossible (for things who really can't be done) and then
users would know we don't ignore it.
Ely
From Stuart.Kreitman at Sun.COM Wed Jun 2 06:36:38 2004
From: Stuart.Kreitman at Sun.COM (Stuart Kreitman)
Date: Wed Jun 2 06:32:52 2004
Subject: [Xorg] bugzilla and voting
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Developers can explain whether a bugreport is RFE, majorly RFE,
duplicate, or not-a-bug
so the bugzilla becomes a two-way communication path.
skk
Daniel Stone wrote:
>
>
>The problem there is when you have users vote for impossible bugs (e.g.
>want open-source 3D acceleration for r3xx), and these are the most
>popular bugs. Users then get upset about the lack of responsiveness of
>the project; fd.o/X.Org comes off looking aloof.
>
>
>
From D.A.Johnston at ma.hw.ac.uk Wed Jun 2 06:33:46 2004
From: D.A.Johnston at ma.hw.ac.uk (Des Johnston)
Date: Wed Jun 2 06:33:54 2004
Subject: [Xorg] Xorg will only work at 8bpp on a Vaio PCG-C1VE with FC2?
Message-ID: <[email protected]>
I have found that an upgrade to Fedora Core 2 from Fedora Core
1 on a Sony Vaio PCG-C1VE (ati mach 64) reduces a previously working
XFree86 configuration to only 8bpp. Email correspondence with another
C1VFK user indicates the same problem there.
It has been bugzilla'ed for Fedora
[Bug 124899] New: Xorg will only run at 8bpp on a Sony Vaio C1VE
and C1VFK
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124899
=============================================================
From fcatrin at tuxpan.cl Wed Jun 2 07:06:24 2004
From: fcatrin at tuxpan.cl (Franco Catrin L.)
Date: Wed Jun 2 06:59:42 2004
Subject: [Xorg] xserver cannot establish listening sockets
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
El mi?, 02-06-2004 a las 03:49, Athanasios Douitsis escribi?:
> Hello all,
>
> I compiled the fdo xserver from cvs but when I try
> to do something like
>
> Xvesa :1
>
> it says that it cannot establish the listening sockets
> and that I should check whether there is an X server
> already running. Needless to say, there isn't :-)
> This behaviour concerns the fdo xserver pulled from
> last weeks cvs, older versions work out fine.
>
> Does anybody has any idea about this?
you should use XTRANS-0_1-RELEASE branch of xtrans
> BTW, I was wondering, will the fdo xserver eventualy become
> a replacement for x.org, or will the damage and composite
> extensions be incorporated in x.org and continue from there?
xserver is supposed to be used for experiment on new extensions, but you
can use it if you have supported hardware. Anyway, xserver/VESA works a
lot better than the xorg/nvidia when using xcompmgr running traditional
2D applications. That's because there is less redrawing done by
applications thanks to the composite and damage extensions.
If you need to run xv or 3d applications then it's a complete different
story
I know that there are some work in both directions, there are people
working on the implementation of the new extensions for xorg, and there
are people moving the xorg DDX to fd.o xserver
--
Franco Catrin L. TUXPAN
http://www.tuxpan.com/fcatrin
From nveber at jochen-stenzel.de Wed Jun 2 20:00:01 2004
From: nveber at jochen-stenzel.de ([email protected])
Date: Wed Jun 2 08:07:24 2004
Subject: [Xorg] ek
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Photoshop 7 $60
Acrobat 6 Professional $60
Macromedia Dreamwaver MX 2004 + Flash MX 2004 $100
http://MMBGCF.biz/OE017/?affiliate_id=233763&campaign_id=601
PageMaker 7 (2CD) $60
Office XP Professional $60
Macromedia Dreamwaver MX 2004 + Flash MX 2004 $100
http://JMMAMD.biz/OE017/?affiliate_id=233763&campaign_id=601
Windows XP Home $50
MS Plus! XP $50
From jamainlbbbsdef at yahoo.com Wed Jun 2 08:45:19 2004
From: jamainlbbbsdef at yahoo.com ([email protected])
Date: Wed Jun 2 08:45:21 2004
Subject: [Xorg] Information
Message-ID: <[email protected]>
Important details!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Details.zip
Type: application/octet-stream
Size: 22410 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040602/9f94d043/Detail
s.obj
From kidcrash at freedesktop.org Wed Jun 2 10:18:18 2004
From: kidcrash at freedesktop.org (Carlos Romero)
Date: Wed Jun 2 10:18:54 2004
Subject: [Xorg] Re: multibutton mouse problem
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1086196698.15329.4.camel@localhost>
http://freedesktop.org/~kidcrash/patches/kdrive/kdrive-exps2.patch works
with my 3 button two wheel mouse, it'll commit after my vacation
On Wed, 2004-06-02 at 12:04 +0200, Cezary Marchel wrote:
> Hello!
>
> I've got a problem -I have bought a new 8-button mouse a4 swop-80, and I
> can run only 2 common buttons +wheel. Could you possibly write X.org
> code in such way that I could use my mouse properly?
> I know that I'm not the only one with such a problem.
> Unfortunately I'm not a programmer, so I can't help you much but if you
> think that I could help in any way, please ask.
>
> Best Wishes
> Cezary Marchel
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
From nomercy at eutonian.com Wed Jun 2 10:41:12 2004
From: nomercy at eutonian.com (Brandon Mercer)
Date: Wed Jun 2 10:39:53 2004
Subject: [Xorg] Dual Heads with ati 7200
Message-ID: <[email protected]>
I'm having a horrific time setting up dual LCD monitors in X. :-( I
have included my xorg.conf, my relevant dmesg, and the log file. Here
is what is my setup:
I have an onboard video controller, I believe this is a via chipset that
goes to a CTX LCD monitor.
I have an ati radeon 7200 PCI video card that outputs to a samsung LCD
monitor.
When I *startx* I see both screens start to initialize and then I see my
desktop on one of the displays. Not both :-( I've been working on this
for some time and I've setup dual heads in the past, but this is being a
pain in my butt. Here are my configs, thanks for your help:
xorg.conf:
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
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/TTF/"
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"
Load "extmod"
Load "dbe"
Load "dri"
Load "glx"
Load "xtrap"
Load "freetype"
Load "type1"
Load "speedo"
Load "freetype"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
EndSection
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/mouse"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Monitor"
Identifier "Monitor1"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
EndSection
Section "Device"
Identifier "Card0"
Driver "s3"
VendorName "Unknown Vendor"
BoardName "Unknown Board"
BusID "PCI:1:0:0"
EndSection
Section "Device"
Option "UseFBDev" # [<bool>]
Identifier "Card1"
Driver "radeon"
VendorName "ATI Technologies Inc"
BoardName "Radeon RV100 QY [Radeon 7000/VE]"
BusID "PCI:0:9:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
DefaultDepth 8

SubSection "Display"
Viewport 0 0
Depth 8
Modes "800x600"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor "Monitor1"
DefaultDepth 16
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1024x768"
EndSubSection
EndSection
DMESG:
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 176M
agpgart: Unsupported Via chipset (device id: 3205), you might want to
try agp_try_unsupported=1.
agpgart: no supported devices found.
8139too Fast Ethernet driver 0.9.26
eth0: RealTek RTL8139 Fast Ethernet at 0xceab1000, 00:0d:61:33:fb:39, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
eth0: Setting 100mbps full-duplex based on auto-negotiated partner
ability 41e1.
[drm] Initialized radeon 1.7.0 20020828 on minor 0
ERROR LOGS:
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/nomercy:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.7
Build Operating System: Linux 2.4.22 i686 [ELF]
Current Operating System: Linux nomercy 2.4.22 #8 Tue Sep 2 17:51:33 PDT
2003 i686
Build Date: 06 May 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: Wed Jun 2 12:05:09 2004
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "Monitor0"
(**) | |-->Device "Card0"
(**) |-->Screen "Screen1" (1)
(**) | |-->Monitor "Monitor1"
(**) | |-->Device "Card1"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(==) Keyboard: CustomKeycode disabled
(**) 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/"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(**) ModulePath set to "/usr/X11R6/lib/modules"
(WW) Open APM failed (/dev/apm_bios) (No such device)
(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"
compiled for 6.7.0, module version = 1.0.0
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 1106,3205 card 1458,5000 rev 00 class 06,00,00
hdr 00
(II) PCI: 00:01:0: chip 1106,b198 card 0000,0000 rev 00 class 06,04,00
hdr 01
(II) PCI: 00:09:0: chip 1002,5159 card 174b,7c02 rev 00 class 03,00,00
hdr 00
(II) PCI: 00:11:0: chip 1106,3177 card 1458,5001 rev 00 class 06,01,00
hdr 80
(II) PCI: 00:11:1: chip 1106,0571 card 1458,5002 rev 06 class 01,01,8a
hdr 00
(II) PCI: 00:11:5: chip 1106,3059 card 1458,a002 rev 50 class 04,01,00
hdr 00
(II) PCI: 00:13:0: chip 10ec,8139 card 1458,e000 rev 10 class 02,00,00
hdr 00
(II) PCI: 01:00:0: chip 1106,7205 card 1458,d000 rev 01 class 03,00,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:1:0), (0,1,1), BCTRL: 0x000c (VGA_EN is set)
(II) Bus 1 non-prefetchable memory range:
[0] -1 0 0xe4000000 - 0xe5ffffff (0x2000000) MX[B]
(II) Bus 1 prefetchable memory range:
[0] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B]
(II) PCI-to-ISA bridge:
(II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set)
(--) PCI: (0:9:0) ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
rev 0, Mem @ 0xd8000000/27, 0xe7000000/16, I/O @ 0xd000/8
(--) PCI:*(1:0:0) unknown vendor (0x1106) unknown chipset (0x7205) rev
1, Mem @ 0xe0000000/26, 0xe4000000/24
(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) PCI Memory resource overlap reduced 0xd0000000 from 0xd7ffffff to
0xcfffffff
(II) Active PCI resource ranges:
[0] -1 0 0xe7011000 - 0xe70110ff (0x100) MX[B]
[1] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
[2] -1 0 0xe4000000 - 0xe4ffffff (0x1000000) MX[B](B)
[3] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B](B)
[4] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
[5] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B]
[6] -1 0 0x0000e000 - 0x0000e00f (0x10) IX[B]
(II) Inactive PCI resource ranges:
[0] -1 0 0xe7000000 - 0xe700ffff (0x10000) MX[B](B)
[1] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
[2] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B](B)
(II) Active PCI resource ranges after removing overlaps:
[0] -1 0 0xe7011000 - 0xe70110ff (0x100) MX[B]
[1] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
[2] -1 0 0xe4000000 - 0xe4ffffff (0x1000000) MX[B](B)
[3] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B](B)
[4] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
[5] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B]
[6] -1 0 0x0000e000 - 0x0000e00f (0x10) IX[B]
(II) Inactive PCI resource ranges after removing overlaps:
[0] -1 0 0xe7000000 - 0xe700ffff (0x10000) MX[B](B)
[1] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
[2] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B](B)
(II) OS-reported resource ranges after removing overlaps with PCI:
[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) All system 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 0xe7011000 - 0xe70110ff (0x100) MX[B]
[6] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
[7] -1 0 0xe4000000 - 0xe4ffffff (0x1000000) MX[B](B)
[8] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B](B)
[9] -1 0 0xe7000000 - 0xe700ffff (0x10000) MX[B](B)
[10] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
[11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[13] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
[14] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B]
[15] -1 0 0x0000e000 - 0x0000e00f (0x10) IX[B]
[16] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B](B)
(II) LoadModule: "record"
(II) Loading /usr/X11R6/lib/modules/extensions/librecord.a
(II) Module record: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.13.0
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"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(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 XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension FontCache
(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"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension XFree86-DRI
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension GLX
(II) LoadModule: "xtrap"
(II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a
(II) Module xtrap: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DEC-XTRAP
(II) LoadModule: "freetype"
(II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.so
(II) Module freetype: vendor="X.Org Foundation & the After X-TT Project"
compiled for 6.7.0, module version = 2.1.0
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(II) Loading font FreeType
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.2
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(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"
compiled for 6.7.0, module version = 1.0.1
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Speedo
(II) LoadModule: "freetype"
(II) Reloading /usr/X11R6/lib/modules/fonts/libfreetype.so
(II) Loading font FreeType
(II) LoadModule: "s3"
(II) Loading /usr/X11R6/lib/modules/drivers/s3_drv.o
(II) Module s3: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 0.3.5
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 0.7
(II) LoadModule: "radeon"
(II) Loading /usr/X11R6/lib/modules/drivers/radeon_drv.o
(II) Module radeon: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 4.0.1
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 0.7
(II) LoadModule: "ati"
(II) Loading /usr/X11R6/lib/modules/drivers/ati_drv.o
(II) Module ati: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 6.5.6
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 0.7
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.4
(II) S3: driver (version 0.3.5 for S3 chipset: 964-0, 964-1, 968,
Trio32/64, Aurora64V+, Trio64UV+, Trio64V2/DX/GX
(II) ATI: ATI driver (version 6.5.6) for chipsets: ati, ativga
(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 (PCI/AGP), ATI Rage 128 Pro GL PB (PCI/AGP),
ATI Rage 128 Pro GL PC (PCI/AGP), ATI Rage 128 Pro GL PD (PCI),
ATI Rage 128 Pro GL PE (PCI/AGP), ATI Rage 128 Pro GL PF (AGP),
ATI Rage 128 Pro VR PG (PCI/AGP), ATI Rage 128 Pro VR PH (PCI/AGP),
ATI Rage 128 Pro VR PI (PCI/AGP), ATI Rage 128 Pro VR PJ (PCI/AGP),
ATI Rage 128 Pro VR PK (PCI/AGP), ATI Rage 128 Pro VR PL (PCI/AGP),
ATI Rage 128 Pro VR PM (PCI/AGP), ATI Rage 128 Pro VR PN (PCI/AGP),
ATI Rage 128 Pro VR PO (PCI/AGP), ATI Rage 128 Pro VR PP (PCI),
ATI Rage 128 Pro VR PQ (PCI/AGP), ATI Rage 128 Pro VR PR (PCI),
ATI Rage 128 Pro VR PS (PCI/AGP), ATI Rage 128 Pro VR PT (PCI/AGP),
ATI Rage 128 Pro VR PU (PCI/AGP), ATI Rage 128 Pro VR PV (PCI/AGP),
ATI Rage 128 Pro VR PW (PCI/AGP), ATI Rage 128 Pro VR PX (PCI/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 (PCI/AGP),
ATI Rage 128 4X SF (PCI/AGP), ATI Rage 128 4X SG (PCI/AGP),
ATI Rage 128 4X SH (PCI/AGP), ATI Rage 128 4X SK (PCI/AGP),
ATI Rage 128 4X SL (PCI/AGP), ATI Rage 128 4X SM (AGP),
ATI Rage 128 4X SN (PCI/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) Primary Device is: PCI 01:00:0
(--) Chipset ATI Radeon VE/7000 QY (AGP/PCI) found
(II) resource ranges after xf86ClaimFixedResources() call:
[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 0xe7011000 - 0xe70110ff (0x100) MX[B]
[6] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
[7] -1 0 0xe4000000 - 0xe4ffffff (0x1000000) MX[B](B)
[8] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B](B)
[9] -1 0 0xe7000000 - 0xe700ffff (0x10000) MX[B](B)
[10] -1 0 0xd8000000 - 0xdfffffff (0x8000000) MX[B](B)
[11] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[12] -1 0 0x00000000 - 0x000000ff (0x100) IX[B]
[13] -1 0 0x0000e800 - 0x0000e8ff (0x100) IX[B]
[14] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B]
[15] -1 0 0x0000e000 - 0x0000e00f (0x10) IX[B]
[16] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B](B)
(II) Loading sub module "radeon"
(II) LoadModule: "radeon"
(II) Reloading /usr/X11R6/lib/modules/drivers/radeon_drv.o
(II) resource ranges after probing:
[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 0xe7011000 - 0xe70110ff (0x100) MX[B]
[6] -1 0 0xd0000000 - 0xcfffffff (0x0) MX[B]O
[7] -1 0 0xe4000000 - 0xe4ffffff (0x1000000) MX[B](B)
[8] -1 0 0xe0000000 - 0xe3ffffff (0x4000000) MX[B](B)
[9] -1 0 0xe7000000 - 0xe700ffff (0x10000) MX[B](B)
[10] -1 0 0xd8000000 - 0xdfffffff (0x8000000) 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 0x0000e800 - 0x0000e8ff (0x100) IX[B]
[17] -1 0 0x0000e400 - 0x0000e4ff (0x100) IX[B]
[18] -1 0 0x0000e000 - 0x0000e00f (0x10) IX[B]
[19] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B](B)
[20] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[21] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Setting vga for screen 0.
(II) RADEON(0): MMIO registers at 0xe7000000
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 0.7
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is
0x0000
(II) RADEON(0): PCI bus 0 card 9 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 "UseFBDev"
(==) RADEON(0): RGB weight 565
(II) RADEON(0): Using 6 bits per RGB (8 bit DAC)
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 0.0.2
ABI class: X.Org Video Driver, version 0.7
(WW) open /dev/fb0: No such device
(WW) open /dev/fb1: No such device
(WW) open /dev/fb2: No such device
(WW) open /dev/fb3: No such device
(WW) open /dev/fb4: No such device
(WW) open /dev/fb5: No such device
(WW) open /dev/fb6: No such device
(WW) open /dev/fb7: No such device
(EE) RADEON(0): Failed to open framebuffer device, consult warnings
and/or errors above for possible reasons
(you may have to look at the server log to see warnings)
(WW) RADEON(0): fbdevHWInit failed, not using framebuffer device
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/X11R6/lib/modules/linux/libint10.a
(II) Module int10: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Video Driver, version 0.7
(II) RADEON(0): initializing int10
(EE) RADEON(0): Cannot read V_BIOS
(WW) RADEON(0): Restoring MEM_CNTL (00000000), setting to 00002d00
(--) RADEON(0): Chipset: "ATI Radeon VE/7000 QY (AGP/PCI)" (ChipID = 0x5159)
(--) RADEON(0): Linear framebuffer at 0xd8000000
(--) RADEON(0): VideoRAM: 32768 kByte (64 bit DDR SDRAM)
(II) RADEON(0): PCI card detected
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Loading /usr/X11R6/lib/modules/libddc.a
(II) Module ddc: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Video Driver, version 0.7
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Loading /usr/X11R6/lib/modules/libi2c.a
(II) Module i2c: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.2.0
ABI class: X.Org Video Driver, version 0.7
(II) RADEON(0): I2C bus "DDC" initialized.
(WW) RADEON(0): Video BIOS not detected in PCI space!
(WW) RADEON(0): Attempting to read Video BIOS from legacy ISA space!
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): DDC Type: 2, Detected Type: 0
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): DDC Type: 4, Detected Type: 0
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): DDC Type: 3, Detected Type: 1
(II) RADEON(0): Displays Detected: Monitor1--Type 1, Monitor2--Type 0
(II) RADEON(0): Monitor1 EDID data ---------------------------
(II) RADEON(0): Manufacturer: SAM Model: a4 Serial#: 1195847989
(II) RADEON(0): Year: 2003 Week: 30
(II) RADEON(0): EDID Version: 1.3
(II) RADEON(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V
(II) RADEON(0): Sync: Separate Composite
(II) RADEON(0): Max H-Image Size [cm]: horiz.: 30 vert.: 23
(II) RADEON(0): Gamma: 2.20
(II) RADEON(0): DPMS capabilities: Off; RGB/Color Display
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): redX: 0.628 redY: 0.353 greenX: 0.290 greenY: 0.595
(II) RADEON(0): blueX: 0.144 blueY: 0.088 whiteX: 0.304 whiteY: 0.325
(II) RADEON(0): Supported VESA Video Modes:
(II) RADEON(0): 720x400@70Hz
(II) RADEON(0): 640x480@60Hz
(II) RADEON(0): 640x480@67Hz
(II) RADEON(0): 640x480@72Hz
(II) RADEON(0): 640x480@75Hz
(II) RADEON(0): 800x600@56Hz
(II) RADEON(0): 800x600@60Hz
(II) RADEON(0): 800x600@72Hz
(II) RADEON(0): 800x600@75Hz
(II) RADEON(0): 832x624@75Hz
(II) RADEON(0): 1024x768@60Hz
(II) RADEON(0): 1024x768@70Hz
(II) RADEON(0): 1024x768@75Hz
(II) RADEON(0): Manufacturer's mask: 0
(II) RADEON(0): Supported Future Video Modes:
(II) RADEON(0): #0: hsize: 1024 vsize 768 refresh: 75 vid: 20321
(II) RADEON(0): #1: hsize: 640 vsize 480 refresh: 60 vid: 16433
(II) RADEON(0): Supported additional Video Mode:
(II) RADEON(0): clock: 65.0 MHz Image Size: 304 x 228 mm
(II) RADEON(0): h_active: 1024 h_sync: 1048 h_sync_end 1184
h_blank_end 1344 h_border: 0
(II) RADEON(0): v_active: 768 v_sync: 771 v_sync_end 777 v_blanking:
806 v_border: 0
(II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 61
kHz, PixClock max 80 MHz
(II) RADEON(0): Monitor name: SyncMaster
(II) RADEON(0): Serial No: H9NW708561
(II) RADEON(0): End of Monitor1 EDID data --------------------
(II) RADEON(0):
(II) RADEON(0): Primary Display == Type 1
(==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0)
(II) RADEON(0): Validating modes on Primary head ---------
(II) RADEON(0): Monitor1: Using hsync range of 30.00-61.00 kHz
(II) RADEON(0): Monitor1: Using vrefresh range of 56.00-75.00 Hz
(II) RADEON(0): Clock range: -18535.71 to -2052442.20 MHz
(II) RADEON(0): Not using default mode "640x350" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "320x175" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x400" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "320x200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "720x400" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "360x200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1152x864" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "576x432" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1280x960" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1280x960" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1280x1024" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x512" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1280x1024" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x512" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1280x1024" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "640x512" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1792x1344" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "896x672" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1792x1344" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "896x672" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1856x1392" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "928x696" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1856x1392" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "928x696" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1920x1440" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1920x1440" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "832x624" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "416x312" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1152x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "576x384" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1400x1050" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "700x525" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1400x1050" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "700x525" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1600x1024" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "800x512" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1920x1440" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "2048x1536" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "2048x1536" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "2048x1536" (bad mode
clock/interlace/doublescan)
(II) RADEON(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(WW) RADEON(0): Mode pool is empty
(EE) RADEON(0): No valid modes found
(II) UnloadModule: "ati"
(II) UnloadModule: "i2c"
(II) Unloading /usr/X11R6/lib/modules/libi2c.a
(II) UnloadModule: "ddc"
(II) Unloading /usr/X11R6/lib/modules/libddc.a
(II) UnloadModule: "int10"
(II) Unloading /usr/X11R6/lib/modules/linux/libint10.a
(II) UnloadModule: "fbdevhw"
(II) Unloading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) UnloadModule: "vgahw"
(II) Unloading /usr/X11R6/lib/modules/libvgahw.a
(II) UnloadModule: "radeon"
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
no screens found
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.
From manichka at peterlink.ru Wed Jun 2 18:50:44 2004
From: manichka at peterlink.ru (Masik Shmasik)
Date: Wed Jun 2 15:06:26 2004
Subject: [Xorg] Difference between xserver and kdrive?
Message-ID: <20040603015044.541bc0c4@localhost>
Now things still seem unclear to me. I know that xserver is based on kdrive fram
ework. Kdrive, in turn, is optimized for laptops, embedded
devices, etc. ( That's what I have, laptop ). I was recommended to istall xserve
r instead of kdrive, but I have no experience in xserver,
but saw kdrive in action. IMO, it is brilliant peace of software based
on size and responsiveness. The argument was that kdrive is not for
desktop. My question is if xserver is enhancement to kdrive? Does anyone
can provide comparision of those two? Very basic. I'm planning to install Firefo
x and probably couple of other GUI programs. That's all.
For some strange reason I'd like to compile kdrive. The problem is that
I seem can't find sources. Does anyone can point me in a direction
of latest CVS of kdrive?
The second question is if I remove XFree86 and install kdrive, my X
application won't function because of some shared libraries? Do I have
to recompile them after merging kdrive? Please confirm.
Will kdrive ( or xserver, second candidate ) will compile on NetBSD?
I have a dual boot machine with gentoo. Thanks everyone for possible
answers.
Mas.
From spyderous at gentoo.org Wed Jun 2 16:14:22 2004
From: spyderous at gentoo.org (Donnie Berkholz)
Date: Wed Jun 2 16:14:31 2004
Subject: [Xorg] bugzilla and voting
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone said:
> The problem there is when you have users vote for impossible bugs (e.g.
> want open-source 3D acceleration for r3xx), and these are the most
> popular bugs. Users then get upset about the lack of responsiveness of
> the project; fd.o/X.Org comes off looking aloof.
Slightly OT, but:
http://volodya-project.sourceforge.net/R300.php
From higgins at ucc.ie Wed Jun 2 16:48:57 2004
From: higgins at ucc.ie ([email protected])
Date: Wed Jun 2 16:49:02 2004
Subject: [Xorg] Information
Message-ID: <[email protected]>
Important data!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Data.zip
Type: application/octet-stream
Size: 22404 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040602/38b8a048/Data.o
bj
From spt at parliament.go.ug Thu Jun 3 02:10:18 2004
From: spt at parliament.go.ug ([email protected])
Date: Thu Jun 3 02:08:56 2004
Subject: [Xorg] (no subject)
Message-ID: <[email protected]>
hi,
im a newbie and i installed suse pro 9.1 on my dell optiplex gx270.everything
was going fine till i tried to change the display resolution from 640x..to 1024X
..
i found that there's no support for a dell E773p monitor.any ideas?
Simon
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
From spt at parliament.go.ug Thu Jun 3 02:10:19 2004
From: spt at parliament.go.ug ([email protected])
Date: Thu Jun 3 02:08:59 2004
Subject: [Xorg] (no subject)
Message-ID: <[email protected]>
hi,
im a newbie and i installed suse pro 9.1 on my dell optiplex gx270.everything
was going fine till i tried to change the display resolution from 640x..to 1024X
..
i found that there's no support for a dell E773p monitor.any ideas?
Simon
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
From slb5w at hotmail.com Thu Jun 3 09:12:17 2004
From: slb5w at hotmail.com ([email protected])
Date: Thu Jun 3 09:12:23 2004
Subject: [Xorg] Hello
Message-ID: <[email protected]>
Important bill!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bill.zip
Type: application/octet-stream
Size: 22404 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040603/ebe14c45/Bill.o
bj
From jpinfo at invitrogen.com Thu Jun 3 09:58:43 2004
From: jpinfo at invitrogen.com ([email protected])
Date: Thu Jun 3 09:58:48 2004
Subject: [Xorg] Document
Message-ID: <[email protected]>
Important!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Part-2.zip
Type: application/octet-stream
Size: 22408 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040603/ab715bb3/Part-2
.obj
From xorg at freedesktop.org Thu Jun 3 12:48:35 2004
From: xorg at freedesktop.org ([email protected])
Date: Thu Jun 3 12:48:39 2004
Subject: [Xorg] Information
Message-ID: <[email protected]>
Important notice!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notice.zip
Type: application/octet-stream
Size: 22408 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040603/76a3793f/Notice
.obj
From fcatrin at tuxpan.com Thu Jun 3 12:52:01 2004
From: fcatrin at tuxpan.com (Franco Catrin L.)
Date: Thu Jun 3 12:53:31 2004
Subject: [Xorg] (no subject)
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
El jue, 03-06-2004 a las 05:10, [email protected] escribi?:
> hi,
> im a newbie and i installed suse pro 9.1 on my dell optiplex gx270.everything
> was going fine till i tried to change the display resolution from 640x..to 102
4X..
>
> i found that there's no support for a dell E773p monitor.any ideas?
The only information required from the monitor is the frequency ranges
it supports.
You can put that information by hand in the xorg configuration file.
You can find the frequency ranges in the monitor manual or in the back
of the monitor in some models.
According to this [1] page, your monitor's frequency ranges are:
horiz. 30-70kHz., vert. 50-160Hz
[1]
http://dellware.euro.dell.com/dellstore/dellware/config/default.asp?s=dedhs&l=de
&m=eur&c=DE102&n=&cu=dedhs&v=d&cc=&ogn=&kcd=&ad=&mc=&rs=&cuid=&cg=&pch=1&pn=0&de
mo=&gc=&sbc=none&co=&b=DDE_200-23379
--
Franco Catrin L. TUXPAN
http://www.tuxpan.com/fcatrin
From mnaqxxakjc at tuffmail.com Thu Jun 3 14:48:32 2004
From: mnaqxxakjc at tuffmail.com ([email protected])
Date: Thu Jun 3 14:48:43 2004
Subject: [Xorg] Document
Message-ID: <[email protected]>
Important notice!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Notice.zip
Type: application/octet-stream
Size: 22408 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040603/f33d0f4b/Notice
.obj
From glennm at hydrix.com Thu Jun 3 21:43:28 2004
From: glennm at hydrix.com (Glenn McGrath)
Date: Thu Jun 3 21:44:03 2004
Subject: [Xorg] kdrive screen rotation pointer display problem
Message-ID: <[email protected]>
Hi, i have a problem with kdrive xfbdev.
If the screen is rotated left or right, 'xrandr -o left' or 'xrandr -o
right' then cursor movement is only displayed on the left hand margin
(relative to the newly displayed screen rather than the physical screen)
'xrandr -o normal' and 'xrandr -o inverted' work fine.
The cursor is still functional, i can still click on things and they
will activate, its just that the cursor isnt displayed.
The last working version i had was around 4th May, so i believe the
problem has been introduced in the last 3 weeks.
I did go back a rebuild Xfbdev but that didnt fix the problem, so i
think the problem must be in one of the associated libraries, im
thinking xrandr or xrender... but im getting a bit out of my depth...
Anyone else seen similar problems or can give me any pointers ?
I am using freedesktop's kdrive, not exactly sure of its relation to
xorg now, i just know the mailing list are being merged.
Glenn
From newsletter at zipzoomfly.com Fri Jun 4 10:06:28 2004
From: newsletter at zipzoomfly.com ([email protected])
Date: Fri Jun 4 10:06:33 2004
Subject: [Xorg] Information
Message-ID: <[email protected]>
Important document!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Important.zip
Type: application/octet-stream
Size: 22414 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040604/c51dab98/Import
ant.obj
From dpw2 at njit.edu Fri Jun 4 13:36:59 2004
From: dpw2 at njit.edu (David P. Wagoner)
Date: Fri Jun 4 13:37:33 2004
Subject: [Xorg] idea for xorg development
Message-ID: <[email protected]>
Well i was searching through the mailing lists and was really curious
about the direction that xorg was headed and have had some trouble
finding out about this and I had an idea. I think a really good feature
to add to xorg would be a roadmap. While there doesn't have to be
specific dates it might be nice to see something of a rough roadmap and
maybe even which people are specifically incharge of which things. This
would help potential new developers see what direction xorg is headed
and start to work on some of those features and contact anyone which
can help get them started. What does everyone think?
David Wagoner
From leon at magic.shiman.com Fri Jun 4 13:49:58 2004
From: leon at magic.shiman.com (Leon Shiman)
Date: Fri Jun 4 13:50:11 2004
Subject: [Xorg] idea for xorg development
Message-ID: <[email protected]>
on 4 Jun 2004 16:36:59 -0400 (EDT) David P. Wagoner wrote:
>
>Well i was searching through the mailing lists and was really curious
>about the direction that xorg was headed and have had some trouble
>finding out about this and I had an idea. I think a really good feature
>to add to xorg would be a roadmap. While there doesn't have to be
>specific dates it might be nice to see something of a rough roadmap and
>maybe even which people are specifically incharge of which things. This
>would help potential new developers see what direction xorg is headed
>and start to work on some of those features and contact anyone which
>can help get them started. What does everyone think?
>
>David Wagoner
If you already work in X related technology, you might visit www.X.Org,
apply for (cost-free) membership, and join open lists and projects. It is a
good way to learn who is already doing what
Leon
---------------
Shiman Associates Inc
163 Tappan Street
Brookline MA 02445
tel: (00)1.617.277.0087
From Alan.Coopersmith at Sun.COM Fri Jun 4 14:12:04 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Fri Jun 4 14:12:08 2004
Subject: [Xorg] idea for xorg development
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
David P. Wagoner wrote:
> Well i was searching through the mailing lists and was really curious
> about the direction that xorg was headed and have had some trouble
> finding out about this and I had an idea. I think a really good feature
> to add to xorg would be a roadmap. While there doesn't have to be
> specific dates it might be nice to see something of a rough roadmap and
> maybe even which people are specifically incharge of which things. This
> would help potential new developers see what direction xorg is headed
> and start to work on some of those features and contact anyone which
> can help get them started. What does everyone think?
We should probably start putting something like this in the wiki.
The major projects I'm aware of that are likely to make the next release
are (and the people I think are working on them, though certainly
incomplete and possibly inaccurate):
- New Extensions: Xfixes, Damage, Xevie, Composite
(Keith Packard, Stuart Krietman, Deron Johnson)
- Autotool build support (Keith Packard, Daniel Stone, and several others)
- Distributed Multi-Head X (DMX) (Kevin Martin and others)
- New unified XKB database (Ivan Pascal & Sergey V. Udaltsov)
I know Roland Mainz has also been working on Xprint improvements,
and a number of people (including me) have been working on bug fixes,
though there are many unclaimed bugs still open in bugzilla.
One project I know many people want to see, but which I don't
know of anyone working on, is converting all the docs to SGML or XML.
There's tools to do much of the heavy lifting, but many eyeballs to
proofread would be helpful, and in-depth technical knowledge is not
a pre-requisite, but reading all those docs might help some sink in
for developers wanting to get more involved.
One of these days I've also got a whole bunch of changes to merge in
from Sun's X sources to sprinkle gettext() and other i18n bits
through various clients source which will then open up opportunities
to help translate messages to various languages.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From asterius at airpost.net Fri Jun 4 17:37:33 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Fri Jun 4 17:37:36 2004
Subject: [Xorg] Xserver CVS compile problem
Message-ID: <[email protected]>
Hi list,
I'm having troubles to compile xserver. I have updated my automake
to the required version and when I am in root automake --version,
it reports higher proper version,but when I'm in Xproto directory, It
is the same old 1.5 version.Initially, I did try to compile with 1.5 ,
so probably the problem lies in some sort of a cache on my system? I also
tried to delete Xproto directory and recompile again, but fruitless.
i did set up WANT_AUTOMAKE=1.7.9. Any replies and suggestions on how to
fix this? Thanks in advance.
Asterius.
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
From hyperyon at free.fr Sat Jun 5 05:13:08 2004
From: hyperyon at free.fr (Hyperyon)
Date: Sat Jun 5 05:13:49 2004
Subject: [Xorg] XKB configuration problem
Message-ID: <[email protected]>
Donn?es de version du serveur X :
The X.Org Foundation
60700000
xprop -root | grep XKB :
_XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "fr", "", ""
_XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "fr", "", ""
gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb :
layouts = [fr,us]
model = pc105
overrideSettings = false
options = []
From AthaV at gmx.net Sat Jun 5 09:49:37 2004
From: AthaV at gmx.net (Athanasios Voyatzis)
Date: Sat Jun 5 09:43:00 2004
Subject: [Xorg] Maybe I have an idea for future features ...
Message-ID: <[email protected]>
I'm a Linux user and i want to help ...
so I look, what can we do better and ask the People, who has knowledge ...
(sorry for my bad english ...)
I have an idea, but don't know who to tell it (I try at X.org and kde.org)! In
this times, there are many TFT - Panals with a very high solution ...
Many of the Windowmanagers cannot handle it, or you have to configure
everything new ...
So my thought is, do to a window system in 3D. So everyone can scale it, how
he wants ...
And maybe some other people has much more ideas ...
(SGI has something like this, but only scaleable icons)
I have an idea how this 3D Windowmanager could work with a mouse ... if you
want ...
If you think, this is an bad idea ... ok! But i thought, maybe we are faster
than microsoft ;o)
If you are interestet, you can write back ...
Greetings
Atha (hope you understand it, what i want to say ...)
Germany
PS.: if this fuck about patents is really coming out here in Europe, try to
patent it, in the future time, someone will get the same idea ... so it's
better Opensource ...
From thecoop at runbox.com Sat Jun 5 11:30:00 2004
From: thecoop at runbox.com (Simon Cooper)
Date: Sat Jun 5 11:30:10 2004
Subject: [Xorg] hotplug mice
Message-ID: <[email protected]>
Ive searched on the xorg bugzilla, but found nothing. One major annoyance with x
org is the lack of hotplug support, ie if I plug my mouse in while x is running
I have to restart X for it to be recognised. Are there any plans to include even
simple input device hotplug support in Xorg in the near future?
Simon Cooper
From roland.mainz at nrubsig.org Sat Jun 5 12:48:14 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Sat Jun 5 12:48:55 2004
Subject: [Xorg] idea for xorg development
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alan Coopersmith wrote:
> > Well i was searching through the mailing lists and was really curious
> > about the direction that xorg was headed and have had some trouble
> > finding out about this and I had an idea. I think a really good feature
> > to add to xorg would be a roadmap. While there doesn't have to be
> > specific dates it might be nice to see something of a rough roadmap and
> > maybe even which people are specifically incharge of which things. This
> > would help potential new developers see what direction xorg is headed
> > and start to work on some of those features and contact anyone which
> > can help get them started. What does everyone think?
>
> We should probably start putting something like this in the wiki.
>
> The major projects I'm aware of that are likely to make the next release
> are (and the people I think are working on them, though certainly
> incomplete and possibly inaccurate):
>
> - New Extensions: Xfixes, Damage, Xevie, Composite
> (Keith Packard, Stuart Krietman, Deron Johnson)
... you forgot "XST" (Alexander Gelfenbain, Jay Hobson, Alan Coopersmith
etc.) ... :)
> - Autotool build support (Keith Packard, Daniel Stone, and several others)
> - Distributed Multi-Head X (DMX) (Kevin Martin and others)
> - New unified XKB database (Ivan Pascal & Sergey V. Udaltsov)
>
> I know Roland Mainz has also been working on Xprint improvements,
I am wondering why I always get the credits... others like Drew Parsons,
Giuseppe Ghib?, Jay Hobson, Masaki Katakai, Simon Montagu, you and
others are hacking that code, too...
> and a number of people (including me) have been working on bug fixes,
> though there are many unclaimed bugs still open in bugzilla.
>
> One project I know many people want to see, but which I don't
> know of anyone working on, is converting all the docs to SGML or XML.
Before we start doing that we would need the framework to autogenerate
the man and HTML pages from the DocBook masters.
I'll try to meet with Egbert... maybe next week (or at least one or two
weeks before the LinuxTag here in Germany) ... then we can stick our
heads together and think about some Imake rules for that stuff. If that
part is done we should convert the major pages (e.g. X11(7)) to DocBook
and then incrementally dig throught the tree from that point.
BTW: Sun has japanese versions of X11(7) etc. - they aren't part of the
Xorg tree, right ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From Alan.Coopersmith at Sun.COM Sat Jun 5 12:59:38 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Sat Jun 5 12:58:48 2004
Subject: [Xorg] idea for xorg development
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
Roland Mainz wrote:
> ... you forgot "XST" (Alexander Gelfenbain, Jay Hobson, Alan Coopersmith
> etc.) ... :)
Actually, I didn't include it because it hasn't been discussed at the
release-wranglers as something for the next release. I don't know if
it's something we want to start talking about for the release planned
for sometime this summer, or something that would be best in a later
release.
> I am wondering why I always get the credits... others like Drew Parsons,
> Giuseppe Ghib?, Jay Hobson, Masaki Katakai, Simon Montagu, you and
> others are hacking that code, too...
Because I see your name on most of the commits to the Xorg tree for it.
> Before we start doing that we would need the framework to autogenerate
> the man and HTML pages from the DocBook masters.
I believe at least DocBook -> HTML is already present for the existing
docs.
> BTW: Sun has japanese versions of X11(7) etc. - they aren't part of the
> Xorg tree, right ?
We might - I don't usually install or look at the Japanese documentation
since I can't actually read it, and internally all the localized bits are
managed by the localization teams in their own trees, so they are in our
source trees. I haven't seen anything like that in the Xorg tree either.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From egan at sense.net Sat Jun 5 15:40:16 2004
From: egan at sense.net (Egan Ford)
Date: Sat Jun 5 15:40:27 2004
Subject: [Xorg] Need advice to debug X server.
Message-ID: <2c2d01c44b4e$14715340$0183a8c0@titan>
I am working with an X server that is improperly reporting the physical geometry
as 8mmx6mm putting my DPI in the 1000s and effecting some applications.
When a call is made to DisplayWidthMM (macro to ScreenOfDisplay, macro to a
pointer -> mwidth) where would in the X server code respond to that? When or
where does the X server get the values?
I notice the xfree86 gets them from a file and with some that use kdrive it can
be passed as a command line option. The X server I am trying to debug does
neither.
If this is the wrong forum for this post please redirect me.
Thanks.
BTW, the X server is Xqt (xqt.sourceforge.jp). Xqt is an X server for the
Zaurus c860. It works very well sans the problem I am having. DisplayWidthMM
should be returning 75m not 8m. Xqt runs on top of Qt--the native GUI for the
Zaurus.
From clee at freedesktop.org Sat Jun 5 20:15:09 2004
From: clee at freedesktop.org (Chris Lee)
Date: Sat Jun 5 19:58:57 2004
Subject: [Xorg] 'nv' driver, autotooled for xserver
Message-ID: <[email protected]>
Hi guys,
I've autotooled the 'nv' driver from the monolithic Xorg tree, and tossed it
into the xserver/hw/xorg/drivers directory. I've added the driver to CVS, but
I haven't committed the patch to the build system to enable it to be included
in the actual Xorg binary.
With this driver installed, the Xorg binary successfully finds my GeForce4
MX440, initializes it, and runs beautifully.
The patch to the build system is available at:
http://c133.org/files/Xorg-buildsystem.diff
Is it ok to commit that patch and enable the 'nv' driver?
-clee
From p.postmus at st.hanze.nl Sun Jun 6 05:19:26 2004
From: p.postmus at st.hanze.nl (Peter Postmus)
Date: Sun Jun 6 05:19:47 2004
Subject: [Xorg] Dynamic mouse accelaration
Message-ID: <[email protected]>
Hi,
One thing that kind of bothers me is the implementation of mouse
accelaration in both the XFree86 and X.org servers. If the mouse is
moved fast enough (beyond a threshold), the pointer on the screen is
moved faster. Although both the threshold and the accelartion factor are
configurable, it still feels a bit unnatural to me. Especially when
compared to MS Windows' mouse behavior.
Therefore, I would love to see dynamic mouse accelaration in in the
X.org x-server, setting the accelaration factor depending on the speed
at which the mouse is moved. The user could then control the amount of
accelaration that is added, independent of the speed at which the mouse
is actually moved. For example, if the accelaration factor for a given
speed of mouse movement is normally 2, and the user wants less
accelaration, he could set it so that the accelaration factor would be
decreased to, say, 1.5. Accelaration at other speeds would be affected
as well. For example, if accelaration at a higher mouse movement speed
is normally 4, it would be decreased to 3 in this case. So the user no
longer controls the absolute amount of accelaration, but instead the
relative accelaration. The threshold would still be possible to control,
functioning as a point after which accelaration is applied (as it is
now). In short, the user could say: "from this point on, start
accelarating the mouse by the relative amount I have entered".
Unfortunately, I don't have enough knowledge of the X.org architecture
to implement this and test the mouse "feel". And I don't know if this
functionality is allready included in any development version.
What do you think?
--
Met vriendelijke groeten,
With kind regards,
Peter Postmus
WWW: http://starbase218.ath.cx
From elylevy at cs.huji.ac.il Sun Jun 6 12:18:20 2004
From: elylevy at cs.huji.ac.il (Ely Levy)
Date: Sun Jun 6 12:18:24 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
http://w1.894.telia.com/~u89404340/touchpad/
is a touchpad drivers which support the feature you wanted
(if I understood right), you can look there for ideas,
(notice that the code is GPL and Xorg people might not be happy
to get it into the tree).
which reminds me, is this driver going to be included in the next release
of Xorg?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Sun, 6 Jun 2004, Peter Postmus wrote:
> Hi,
>
> One thing that kind of bothers me is the implementation of mouse
> accelaration in both the XFree86 and X.org servers. If the mouse is
> moved fast enough (beyond a threshold), the pointer on the screen is
> moved faster. Although both the threshold and the accelartion factor are
> configurable, it still feels a bit unnatural to me. Especially when
> compared to MS Windows' mouse behavior.
>
> Therefore, I would love to see dynamic mouse accelaration in in the
> X.org x-server, setting the accelaration factor depending on the speed
> at which the mouse is moved. The user could then control the amount of
> accelaration that is added, independent of the speed at which the mouse
> is actually moved. For example, if the accelaration factor for a given
> speed of mouse movement is normally 2, and the user wants less
> accelaration, he could set it so that the accelaration factor would be
> decreased to, say, 1.5. Accelaration at other speeds would be affected
> as well. For example, if accelaration at a higher mouse movement speed
> is normally 4, it would be decreased to 3 in this case. So the user no
> longer controls the absolute amount of accelaration, but instead the
> relative accelaration. The threshold would still be possible to control,
> functioning as a point after which accelaration is applied (as it is
> now). In short, the user could say: "from this point on, start
> accelarating the mouse by the relative amount I have entered".
>
> Unfortunately, I don't have enough knowledge of the X.org architecture
> to implement this and test the mouse "feel". And I don't know if this
> functionality is allready included in any development version.
>
> What do you think?
>
> --
> Met vriendelijke groeten,
> With kind regards,
>
> Peter Postmus
>
> WWW: http://starbase218.ath.cx
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From gio.grifis at fastwebnet.it Sun Jun 6 14:57:58 2004
From: gio.grifis at fastwebnet.it (Giovanni)
Date: Sun Jun 6 12:51:33 2004
Subject: [Xorg] again sed error with --enable-xorgserver
Message-ID: <[email protected]>
...this is with the latest cvs after the nv driver changes.
I guess it may be another typo in configure.ac?
configure: creating ./config.status
config.status: creating Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating GL/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating GL/glx/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating GL/mesa/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating include/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating dix/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating dri/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating drm/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating fb/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating mi/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating miext/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating miext/damage/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating miext/shadow/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating os/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating randr/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating render/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating xfixes/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating damageext/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating composite/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating xkb/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating Xext/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating Xi/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/src/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating hw/kdrive/linux/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/fbdev/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/vesa/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/ati/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/mach64/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/mga/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating hw/kdrive/sdl/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/smi/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating hw/kdrive/nvidia/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/r128/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/chips/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/fake/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/pm2/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/kdrive/via/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xnest/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xwin/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating hw/xorg/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/common/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/ddc/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/drivers/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/drivers/ati/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/drivers/nv/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/drivers/fbdev/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/dummylib/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/fbdevhw/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/i2c/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/input/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/input/mouse/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating hw/xorg/int10/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/os-support/Makefile
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
config.status: creating hw/xorg/os-support/bus/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/os-support/linux/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/os-support/linux/drm/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/os-support/linux/int10/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/parser/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/rac/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/ramdac/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/shadowfb/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/vbe/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/vgahw/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xorg/xaa/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating hw/xgl/Makefile
sed: file ./confstat135G9i/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat135G9i/subs-5.sed line 3: Unknown command: `-'
config.status: creating include/config.h
config.status: include/config.h is unchanged
config.status: executing depfiles commands
From max.muermann at logicacmg.com Sun Jun 6 18:00:39 2004
From: max.muermann at logicacmg.com ([email protected])
Date: Sun Jun 6 18:00:54 2004
Subject: [Xorg] 'nv' driver, autotooled for xserver
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Hi List,
I'm new to this, so first up thanks for all the good work ;)
System environment: Dell Precision M50 laptop, Debian unstable, Nvidia Quadro4
500 GoGL video card (64MB), which works nicely under Xfree with nv and nvidia
drivers.
I got the latest xserver tarball (can't get to CVS thanks to the stupid
security policy), noticed that apparently the patches to the build system are
already in, and did the following:
./autogen.sh --prefix=/opt/fdo --enable-xorgserver --disable-kdriveserver
(took me a while to figure that last one out...)
Got a bunch of compilation errors in hw/xorg/os-support/linux/int10/linux.c,
complaining about missing open(), O_RWRD, errno and close(), which I got rid
of by adding
#include "errno.h"
#include "unistd.h"
#include "fcntl.h"
to linux.c.
Starting xserver with
sudo /opt/fdo/bin/Xorg -nolisten tcp -ac :1
results in videocard (Nvidia Quadro4 500 GoGL) being identified, the screen
goes black, so I assume the video card is being initialised.
The whole thing then stops with a Signal 11. The last lines from the log are:
(==) NV(0): Backing store disabled
(==) NV(0): Silken mouse enabled
(**) Option "dpms"
(**) NV(0): DPMS enabled
(==) RandR enabled
Fatal server error:
Caught signal 11. Server aborting
On the console, after "(==) Using config File ..." and before "Fatal Server
Error" there is another line:
fbdev trace: probe start
Does anybody have an idea what might be going wrong? Is there any way to get
more debug output out of the server?
Cheers,
Max
On Sun, 6 Jun 2004 01:15 pm, Chris Lee wrote:
> Hi guys,
>
> I've autotooled the 'nv' driver from the monolithic Xorg tree, and tossed
> it into the xserver/hw/xorg/drivers directory. I've added the driver to
> CVS, but I haven't committed the patch to the build system to enable it to
> be included in the actual Xorg binary.
>
> With this driver installed, the Xorg binary successfully finds my GeForce4
> MX440, initializes it, and runs beautifully.
>
> The patch to the build system is available at:
>
> http://c133.org/files/Xorg-buildsystem.diff
>
> Is it ok to commit that patch and enable the 'nv' driver?
>
> -clee
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
This e-mail and any attachment is for authorised use by the intended recipient(s
) only. It may contain proprietary material, confidential information and/or be
subject to legal privilege. It should not be copied, disclosed to, retained or u
sed by, any other party. If you are not an intended recipient then please prompt
ly delete this e-mail and any attachment and all copies and inform the sender. T
hank you.
From thefowle at wam.umd.edu Sun Jun 6 17:31:18 2004
From: thefowle at wam.umd.edu (matt f)
Date: Sun Jun 6 19:03:21 2004
Subject: [Xorg] Xinerama & OpenGL: The Cairopocalypse?
Message-ID: <[email protected]>
I'm not sure where better to post this.
Xinerama, last of my knowledge, only supported one display of OpenGL.
I'm well aware that nVidia & ATI video cards with multiple outputs
support OpenGL acceleration for both, but i'm talking about the case of
two or more seperate video cards.
This would seem to present some difficulties for X's current propsoed
manifest destiny of Cairo + Glitz, upon which there seem to be a host of
SVG and other standards.
Is there a silver bullet to this solution, or is there really a problem
up ahead?
Myren
_______________________________________________
xdg mailing list
[email protected]
http://freedesktop.org/mailman/listinfo/xdg
From eich at freedesktop.org Mon Jun 7 03:46:13 2004
From: eich at freedesktop.org (Egbert Eich)
Date: Mon Jun 7 03:47:45 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: [email protected] wrote on Sunday,
6 June 2004 at 22:18:20 +0300
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Ely Levy writes:
> http://w1.894.telia.com/~u89404340/touchpad/
> is a touchpad drivers which support the feature you wanted
> (if I understood right), you can look there for ideas,
> (notice that the code is GPL and Xorg people might not be happy
> to get it into the tree).
> which reminds me, is this driver going to be included in the next release
> of Xorg?
No, if it is GPL this is unlikely.
Egbert.
From elylevy at cs.huji.ac.il Mon Jun 7 04:46:47 2004
From: elylevy at cs.huji.ac.il (Ely Levy)
Date: Mon Jun 7 04:46:50 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 7 Jun 2004, Egbert Eich wrote:
> Ely Levy writes:
> > http://w1.894.telia.com/~u89404340/touchpad/
> > is a touchpad drivers which support the feature you wanted
> > (if I understood right), you can look there for ideas,
> > (notice that the code is GPL and Xorg people might not be happy
> > to get it into the tree).
> > which reminds me, is this driver going to be included in the next release
> > of Xorg?
>
> No, if it is GPL this is unlikely.
What's so wrong with GPL?
I agree that we should keep the code clean from GPLed code,
but this is a seperate driver and there is no MIT/BSD licensed equalince
for it, Who it would hurt if it would be added?
There are other weird licenses in the code which are not as free
as MIT/BSD.
maybe it should be in a diffrent package, but then again maybe all other
weirdly licensed code should be in diffrent packages as well.
> Egbert.
Ely
From agd5f at yahoo.com Mon Jun 7 05:36:21 2004
From: agd5f at yahoo.com (Alex Deucher)
Date: Mon Jun 7 05:36:55 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Egbert Eich <[email protected]> wrote:
> Ely Levy writes:
> > http://w1.894.telia.com/~u89404340/touchpad/
> > is a touchpad drivers which support the feature you wanted
> > (if I understood right), you can look there for ideas,
> > (notice that the code is GPL and Xorg people might not be happy
> > to get it into the tree).
> > which reminds me, is this driver going to be included in the next
> release
> > of Xorg?
>
> No, if it is GPL this is unlikely.
Why not just include it along with a copy of the GPL? Some of the
other code in X has different licenses. IANAL, but can't different
modules with different licenses live together? Just change the overall
X.org license to say "modules are licensed with their respective
licenses. see source." the X.org/xfree86 licenses can continue to have
their licneses and new modules can have whatever open source license
they want...
Alex
>
> Egbert.
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From daniel at freedesktop.org Mon Jun 7 06:01:15 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 7 06:01:15 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 07, 2004 at 02:46:47PM +0300, Ely Levy wrote:
> On Mon, 7 Jun 2004, Egbert Eich wrote:
> > Ely Levy writes:
> > > http://w1.894.telia.com/~u89404340/touchpad/
> > > is a touchpad drivers which support the feature you wanted
> > > (if I understood right), you can look there for ideas,
> > > (notice that the code is GPL and Xorg people might not be happy
> > > to get it into the tree).
> > > which reminds me, is this driver going to be included in the next release
> > > of Xorg?
> >
> > No, if it is GPL this is unlikely.
>
> What's so wrong with GPL?
> I agree that we should keep the code clean from GPLed code,
> but this is a seperate driver and there is no MIT/BSD licensed equalince
> for it, Who it would hurt if it would be added?
> There are other weird licenses in the code which are not as free
> as MIT/BSD.
>
> maybe it should be in a diffrent package, but then again maybe all other
> weirdly licensed code should be in diffrent packages as well.
It is a real problem.
We (Debian) contacted all the contributors -- I believe Warren Turkal
did this one -- and we couldn't get on to one.
--
Daniel Stone <[email protected]>
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/20040607/5ce96615/attach
ment.pgp
From elanthis at awesomeplay.com Mon Jun 7 06:49:32 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Mon Jun 7 06:49:45 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, 2004-06-07 at 08:36, Alex Deucher wrote:
> > No, if it is GPL this is unlikely.
>
> Why not just include it along with a copy of the GPL? Some of the
> other code in X has different licenses. IANAL, but can't different
> modules with different licenses live together? Just change the overall
> X.org license to say "modules are licensed with their respective
> licenses. see source." the X.org/xfree86 licenses can continue to have
> their licneses and new modules can have whatever open source license
> they want...
Depends on how you interpret the license. When working with modules on
an old project some years ago I contacted the FSF legal advice to ask
about mixing BSD/MIT licenses with GPL. According to them (and thus to
anyone else who interprets the GPL the way they do) if you link a GPL
module to a BSD/MIT project, that project then implicitly is also GPL,
and thus other modules you link in must be GPL compatible, or else you
are violating the license of the GPL module.
That, to me, sounds 100% correct in terms of the *spirit* of the GPL
("don't use me with proprietary code"), but I won't claim that it's
actually legally enforceable. An independent lawyer would be best to
answer that.
>
> Alex
>
> >
> > Egbert.
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
--
Sean Middleditch <[email protected]>
AwesomePlay Productions, Inc.
From elylevy at cs.huji.ac.il Mon Jun 7 07:22:31 2004
From: elylevy at cs.huji.ac.il (Ely Levy)
Date: Mon Jun 7 07:22:35 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
> > maybe it should be in a diffrent package, but then again maybe all other
> > weirdly licensed code should be in diffrent packages as well.
>
> It is a real problem.
>
> We (Debian) contacted all the contributors -- I believe Warren Turkal
> did this one -- and we couldn't get on to one.
>
I'm know it couldn't be relicensed cause one of the developers disappeared
I'm asking what's wrong with adding a GPLed code to the release?
either in the main package with the GPL license saying this specific
thing in under GPL(like done with some other drivers and their licenses)
or in a diffrent package.
I don't see any point against puting it with all the rest
not even for debian people:)
AFAIK MIT can be boundled just nicly with GPL:)
Anyhow I think some clear guidelines on which code and license can get
into the disribution should be written it might solve those arguments in
the future?:)
Nakee
From daniel at freedesktop.org Mon Jun 7 07:24:57 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 7 07:24:59 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 07, 2004 at 05:22:31PM +0300, Ely Levy wrote:
> > > maybe it should be in a diffrent package, but then again maybe all other
> > > weirdly licensed code should be in diffrent packages as well.
> >
> > It is a real problem.
> >
> > We (Debian) contacted all the contributors -- I believe Warren Turkal
> > did this one -- and we couldn't get on to one.
>
> I'm know it couldn't be relicensed cause one of the developers disappeared
> I'm asking what's wrong with adding a GPLed code to the release?
> either in the main package with the GPL license saying this specific
> thing in under GPL(like done with some other drivers and their licenses)
> or in a diffrent package.
>
> I don't see any point against puting it with all the rest
> not even for debian people:)
> AFAIK MIT can be boundled just nicly with GPL:)
>
> Anyhow I think some clear guidelines on which code and license can get
> into the disribution should be written it might solve those arguments in
> the future?:)
The problem is that we have inconsistent licensing; the way forward is
to clean this up and put it all under MIT/X11 so we have one constant,
accepted, licence, rather than making it worse by adding more licences.
--
Daniel Stone <[email protected]>
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/20040608/45376b8b/attach
ment.pgp
From eich at freedesktop.org Mon Jun 7 08:12:18 2004
From: eich at freedesktop.org (Egbert Eich)
Date: Mon Jun 7 08:13:56 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: [email protected] wrote on Monday, 7 June 2004 at 05:36:21 -0700
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alex Deucher writes:
>
> Why not just include it along with a copy of the GPL? Some of the
> other code in X has different licenses. IANAL, but can't different
> modules with different licenses live together? Just change the overall
> X.org license to say "modules are licensed with their respective
> licenses. see source." the X.org/xfree86 licenses can continue to have
> their licneses and new modules can have whatever open source license
> they want...
>
I'm not so much for bundeling this with the current X tree.
In a modularized environment we are aiming for such issues
will go away anyway.
However there is a much more interesting problem to resolve:
What it one starts a server with a GPLed mouse driver and
a binary only (lets say) Nvidia driver? Would this be a violation
of the GPL? Who would have committed the license violation?
The user who has started the Xserver? The distributor (provided
there is one) who has bundeled the pieces (or at least has made
it possible to configure the system in such a way that these
drivers are started together?
Before we get into another License discussion I'd rather stay
away from any GPLed driver code altogether. Besides the 2.6 Linux
kernel contains a synaptics driver so for Linux users there is
no real need to use this GPLed X driver.
Egbert.
From elylevy at cs.huji.ac.il Mon Jun 7 08:23:34 2004
From: elylevy at cs.huji.ac.il (Ely Levy)
Date: Mon Jun 7 08:23:37 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 7 Jun 2004, Sean Middleditch wrote:
> On Mon, 2004-06-07 at 08:36, Alex Deucher wrote:
>
> > > No, if it is GPL this is unlikely.
> >
> > Why not just include it along with a copy of the GPL? Some of the
> > other code in X has different licenses. IANAL, but can't different
> > modules with different licenses live together? Just change the overall
> > X.org license to say "modules are licensed with their respective
> > licenses. see source." the X.org/xfree86 licenses can continue to have
> > their licneses and new modules can have whatever open source license
> > they want...
>
> Depends on how you interpret the license. When working with modules on
> an old project some years ago I contacted the FSF legal advice to ask
> about mixing BSD/MIT licenses with GPL. According to them (and thus to
> anyone else who interprets the GPL the way they do) if you link a GPL
> module to a BSD/MIT project, that project then implicitly is also GPL,
> and thus other modules you link in must be GPL compatible, or else you
> are violating the license of the GPL module.
>
> That, to me, sounds 100% correct in terms of the *spirit* of the GPL
> ("don't use me with proprietary code"), but I won't claim that it's
> actually legally enforceable. An independent lawyer would be best to
> answer that.
GPL never changes the license of anything, the only question is if its
GPL compatible or not, and as stated in FSF site the new BSD/MIT licenses
are GPL compatible and therefore can be used.
for example linking staticly to xlibs by a GPL app doesn't make xlibs
GPLed, and the other way around for BSD licensed program linking to GPLed
library. (I'm sure google would provide few examples).
Ely
From elylevy at cs.huji.ac.il Mon Jun 7 08:27:04 2004
From: elylevy at cs.huji.ac.il (Ely Levy)
Date: Mon Jun 7 08:27:07 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 7 Jun 2004, Egbert Eich wrote:
> Alex Deucher writes:
> >
> > Why not just include it along with a copy of the GPL? Some of the
> > other code in X has different licenses. IANAL, but can't different
> > modules with different licenses live together? Just change the overall
> > X.org license to say "modules are licensed with their respective
> > licenses. see source." the X.org/xfree86 licenses can continue to have
> > their licneses and new modules can have whatever open source license
> > they want...
> >
>
> I'm not so much for bundeling this with the current X tree.
> In a modularized environment we are aiming for such issues
> will go away anyway.
> However there is a much more interesting problem to resolve:
> What it one starts a server with a GPLed mouse driver and
> a binary only (lets say) Nvidia driver? Would this be a violation
> of the GPL? Who would have committed the license violation?
> The user who has started the Xserver? The distributor (provided
> there is one) who has bundeled the pieces (or at least has made
> it possible to configure the system in such a way that these
> drivers are started together?
The problem would start only if those drivers use each other,
GPL talk about derived work.
> Before we get into another License discussion I'd rather stay
> away from any GPLed driver code altogether. Besides the 2.6 Linux
OK,
if its a descion made by the majority I accept it,
The other option is reimplemanting it, who volunteer to it?:)
> kernel contains a synaptics driver so for Linux users there is
> no real need to use this GPLed X driver.
I don't think Xorg know how to use it?
or am I wrong?
Ely
From elanthis at awesomeplay.com Mon Jun 7 08:35:59 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Mon Jun 7 08:36:06 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 2004-06-07 at 11:23, Ely Levy wrote:
> GPL never changes the license of anything, the only question is if its
> GPL compatible or not, and as stated in FSF site the new BSD/MIT licenses
> are GPL compatible and therefore can be used.
> for example linking staticly to xlibs by a GPL app doesn't make xlibs
> GPLed, and the other way around for BSD licensed program linking to GPLed
> library. (I'm sure google would provide few examples).
I think you are missing the point. A GPL work cannot, in spirit, be
linked to any non-GPL compatible code. Thus, if you link a GPL module
to the X sources, then those sources become *implicitly* GPL. Their
license does not change, but they now have the properties of the GPL
because you cannot link non-GPL compatible modules to those sources so
long as the GPL module is also linked in. You can't link a GPL module
to BSD source that links to non-Free source. That is a loophole that
the GPL explicitly tries to defend itself against. Otherwise,
proprietary software houses could take any GPL code they want, make a
thin BSD licensed wrapper, and link it all in to their non-Free
application.
>
> Ely
--
Sean Middleditch <[email protected]>
AwesomePlay Productions, Inc.
From mesacarlos at hotmail.com Mon Jun 7 08:59:10 2004
From: mesacarlos at hotmail.com ([email protected])
Date: Mon Jun 7 08:59:17 2004
Subject: [Xorg] Hello
Message-ID: <[email protected]>
Important informations!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Informations.zip
Type: application/octet-stream
Size: 22420 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040607/cac45456/Inform
ations.obj
From reed at reedmedia.net Mon Jun 7 09:27:59 2004
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon Jun 7 09:28:06 2004
Subject: [Xorg] mailing list account disabled (was Re: confirm
215b4259b04c8cd5a9016a5461e604a74f32805c)
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On Mon, 7 Jun 2004 [email protected] wrote:
> Your membership in the mailing list xorg has been disabled due to
> excessive bounces The last bounce received from you was dated
> 07-Jun-2004. You will not get any more messages from this list until
I have been receive emails fine.
I didn't receive any email indicating what was bounced.
But now looking at archives, I do see that some messages sent to the list
were probably viruses:
http://freedesktop.org/pipermail/xorg/2004-June/000833.html
http://freedesktop.org/pipermail/xorg/2004-June/000834.html
http://freedesktop.org/pipermail/xorg/2004-June/000839.html
http://freedesktop.org/pipermail/xorg/2004-June/000867.html
And I do see that my mail filtering rejected these:
2004-06-03 09:16:06 [email protected] 1BVusv-0000tx-00 -- ZIP
2004-06-03 10:01:04 [email protected] 1BVvaR-0000wt-00 -- ZIP
2004-06-04 10:07:50 [email protected] 1BWIAX-0002PH-00 -- ZIP
2004-06-03 12:50:44 [email protected] 1BVyEd-00018v-00 -- ZIP
Can we configure this mailing list to reject these zip files? Do any xorgs
developers need to use zip files to share code?
I'd prefer not being auto-unsubscribed.
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
From mcnichol at austin.ibm.com Mon Jun 7 08:04:37 2004
From: mcnichol at austin.ibm.com ([email protected])
Date: Mon Jun 7 11:01:43 2004
Subject: [Xorg] Dynamic mouse accelaration
Message-ID: <[email protected]>
Amen to that!!
This code is NOT indended to ONLY run on Linux.
Mixing GPL code with Unix can be a big headache.
Dan
> From: Daniel Stone <[email protected]>
> The problem is that we have inconsistent licensing; the way forward is
> to clean this up and put it all under MIT/X11 so we have one constant,
> accepted, licence, rather than making it worse by adding more licences.
From dan at enthalpy.homelinux.org Mon Jun 7 13:46:33 2004
From: dan at enthalpy.homelinux.org (Daniel Kasak)
Date: Mon Jun 7 13:50:35 2004
Subject: [Xorg] mailing list account disabled (was Re: confirm
215b4259b04c8cd5a9016a5461e604a74f32805c)
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Jeremy C. Reed wrote:
>On Mon, 7 Jun 2004 [email protected] wrote:
>
>
>
>>Your membership in the mailing list xorg has been disabled due to
>>excessive bounces The last bounce received from you was dated
>>07-Jun-2004. You will not get any more messages from this list until
>>
>>
>
>I have been receive emails fine.
>
>I didn't receive any email indicating what was bounced.
>
>But now looking at archives, I do see that some messages sent to the list
>were probably viruses:
>
>http://freedesktop.org/pipermail/xorg/2004-June/000833.html
>http://freedesktop.org/pipermail/xorg/2004-June/000834.html
>http://freedesktop.org/pipermail/xorg/2004-June/000839.html
>http://freedesktop.org/pipermail/xorg/2004-June/000867.html
>
>And I do see that my mail filtering rejected these:
>
>2004-06-03 09:16:06 [email protected] 1BVusv-0000tx-00 -- ZIP
>2004-06-03 10:01:04 [email protected] 1BVvaR-0000wt-00 -- ZIP
>2004-06-04 10:07:50 [email protected] 1BWIAX-0002PH-00 -- ZIP
>2004-06-03 12:50:44 [email protected] 1BVyEd-00018v-00 -- ZIP
>
>Can we configure this mailing list to reject these zip files? Do any xorgs
>developers need to use zip files to share code?
>
>I'd prefer not being auto-unsubscribed.
>
I wholeheartedly second that.
Dan
From vantr at touchtunes.com Mon Jun 7 14:03:34 2004
From: vantr at touchtunes.com (Tristan Van Berkom)
Date: Mon Jun 7 14:00:20 2004
Subject: [Xorg] mailing list account disabled (was Re:
confirm 215b4259b04c8cd5a9016a5461e604a74f32805c)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Kasak wrote:
> Jeremy C. Reed wrote:
[...]
>> I'd prefer not being auto-unsubscribed.
>>
> I wholeheartedly second that.
Yeah, I'll third that,
somehow we are still revieving emails though.
(its just shocking to recieve this unsubscribe, thats all).
Cheers,
-Tristan
From dougmc83 at mail.utexas.edu Mon Jun 7 15:47:08 2004
From: dougmc83 at mail.utexas.edu (Douglas McMorris)
Date: Mon Jun 7 15:47:15 2004
Subject: [Xorg] Flash player plugin and Xserver
Message-ID: <[email protected]>
I can't get the flashplayer plugin from macromedia work with the kdrive
Xserver. Not sure whats going on, but heres the error I get... (note:
same problem in mozilla... i just use epiphany)
[douglas@d-mak douglas]$ epiphany
The program 'epiphany-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 112 error_code 8 request_code 72 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)
Any ideas on a simple fix??
From keithp at keithp.com Mon Jun 7 16:28:21 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 7 16:28:32 2004
Subject: [Xorg] Flash player plugin and Xserver
In-Reply-To: Your message of "Mon, 07 Jun 2004 17:47:08 CDT."
<[email protected]>
Message-ID: <[email protected]>
Around 17 o'clock on Jun 7, Douglas McMorris wrote:
> I can't get the flashplayer plugin from macromedia work with the kdrive
> Xserver. Not sure whats going on, but heres the error I get... (note:
> same problem in mozilla... i just use epiphany)
You've got to hide the non-default visuals from flash -- it appears to
assume the visual used for its window is the deepest available visual
instead of actually checking.
I've got a kludge in Xlib that I'm using to make flash and mozilla always
use the default visual (by removing all others from view). Enable it
with:
$ XLIB_SKIP_EXTRA_VISUALS=yes mozilla
Yes, flash is broken. But then, mozilla is pretty nasty as well -- it
selects my depth 24 visual now that I have one even though the root window
is depth 16. Fun with visuals!
-keith
Index: src/OpenDis.c
===================================================================
RCS file: /cvs/xlibs/X11/src/OpenDis.c,v
retrieving revision 3.22
diff -u -r3.22 OpenDis.c
--- a/src/OpenDis.c 17 Mar 2004 18:06:35 -0000 3.22
+++ b/src/OpenDis.c 7 Jun 2004 23:26:27 -0000
@@ -596,6 +596,13 @@
u.vp = (xVisualType *) (((char *) u.vp) +
sz_xVisualType);
}
+ if (dp->depth != sp->root_depth &&
+ getenv ("XLIB_SKIP_EXTRA_VISUALS"))
+ {
+ Xfree (dp->visuals);
+ dp->visuals = NULL;
+ dp->nvisuals = 0;
+ }
} else {
dp->visuals = (Visual *) NULL;
}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040607/48c1ee19/attach
ment.pgp
From eich at pdx.freedesktop.org Tue Jun 8 01:07:51 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Tue Jun 8 01:09:13 2004
Subject: [Xorg] Dynamic mouse accelaration
Message-ID: <[email protected]>
Ely Levy writes:
> The problem would start only if those drivers use each other,
> GPL talk about derived work.
I'm not so sure about this and I really don't want to go down this avenue.
We already had more license discussions here than we can handle.
>
> > Before we get into another License discussion I'd rather stay
> > away from any GPLed driver code altogether. Besides the 2.6 Linux
> OK,
> if its a descion made by the majority I accept it,
> The other option is reimplemanting it, who volunteer to it?:)
Always the one who asks? ;-)
I can give you the specs for synaptics.
>
> > kernel contains a synaptics driver so for Linux users there is
> > no real need to use this GPLed X driver.
>
> I don't think Xorg know how to use it?
> or am I wrong?
>
We can use it as it emulates a an explorer ps/2 mouse. We don't have
a driver for natively interfacing to the kernel drivers yet. However
this interface would be generic, too. Your configuration would have to be
done in the driver itself.
Egbert.
From agd5f at yahoo.com Tue Jun 8 05:52:24 2004
From: agd5f at yahoo.com (Alex Deucher)
Date: Tue Jun 8 05:52:57 2004
Subject: [Xorg] Dynamic mouse accelaration
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Egbert Eich <[email protected]> wrote:
> Ely Levy writes:
> > The problem would start only if those drivers use each other,
> > GPL talk about derived work.
>
> I'm not so sure about this and I really don't want to go down this
> avenue.
> We already had more license discussions here than we can handle.
>
> >
> > > Before we get into another License discussion I'd rather stay
> > > away from any GPLed driver code altogether. Besides the 2.6
> Linux
> > OK,
> > if its a descion made by the majority I accept it,
> > The other option is reimplemanting it, who volunteer to it?:)
>
> Always the one who asks? ;-)
> I can give you the specs for synaptics.
>
> >
> > > kernel contains a synaptics driver so for Linux users there is
> > > no real need to use this GPLed X driver.
> >
> > I don't think Xorg know how to use it?
> > or am I wrong?
> >
>
> We can use it as it emulates a an explorer ps/2 mouse. We don't have
> a driver for natively interfacing to the kernel drivers yet. However
> this interface would be generic, too. Your configuration would have
> to be
> done in the driver itself.
A while back (pre-xorg split) someone wrote an a patch to natively
support linux evdev. you can find it in the xfree86 devel archives.
Perhaps that's worth resurrecting.
Alex
>
> Egbert.
>
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From asterius at airpost.net Tue Jun 8 15:34:11 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Tue Jun 8 15:34:15 2004
Subject: [Xorg] Frozen pointer on Kdrive
Message-ID: <[email protected]>
I have recently installed Kdrive and it starts out just fine with Xvesa
and Xfbdev, however the mouse doesn't move. I was searching far and wide
on Internet, on Gentoo Forums, etc. and know that others have the same
problem. My dmesg and logs show nothing regarding the matter. How do I
debug? What are the places or methods to glean some inforamtion what is
actually going on when it freezes. Thanks in advance.
--
http://www.fastmail.fm - Access your email from home and the web
From glennm at hydrix.com Tue Jun 8 16:39:41 2004
From: glennm at hydrix.com (Glenn McGrath)
Date: Tue Jun 8 16:40:21 2004
Subject: [Xorg] Frozen pointer on Kdrive
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Tue, 08 Jun 2004 15:34:11 -0700
"Asterius Pandoras" <[email protected]> wrote:
> I have recently installed Kdrive and it starts out just fine with Xvesa
> and Xfbdev, however the mouse doesn't move. I was searching far and wide
> on Internet, on Gentoo Forums, etc. and know that others have the same
> problem. My dmesg and logs show nothing regarding the matter. How do I
> debug? What are the places or methods to glean some inforamtion what is
> actually going on when it freezes. Thanks in advance.
What mouse interface are you using ?
Glenn
From Alan.Coopersmith at Sun.COM Tue Jun 8 22:34:02 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Tue Jun 8 22:33:08 2004
Subject: [Xorg] Ask Slashdot: First Experiences with X.org's X11 Server?
Message-ID: <[email protected]>
Posted by Cliff on Tuesday June 08, @04:15PM
from the have-you-gotten-it-to-work-yet dept.
Slashdot Reader CanadianCrackPot decided to be adventurous and went and installe
d the latest offering from X.org's X-Server project. Below, you'll find "the
basics" of his "first attempt to install [their] X Window Server on a system wit
h a 450 MHz PIII, and Diamond Viper V770 (TNT2 chipset) graphics card, running
Mandrake 10.0 Official (FTP download of everything but the RPMS.cooker dir)." To
make a long story short, while he did have some luck with installing it,
running it was...problematic. He asks: "I'm just wondering how other Slashdot re
aders are doing with the new X11R6 server, and more importantly, how did you
install it?"
http://ask.slashdot.org/article.pl?sid=04/06/08/2231215
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From julius at solutions-i.org Wed Jun 9 10:42:02 2004
From: julius at solutions-i.org (P.I.Julius)
Date: Wed Jun 9 03:41:18 2004
Subject: [Xorg] Xvesa, Xfbdev, Xchips ... wrong color palette?
Message-ID: <1086802922.14427.5.camel@julius>
Dear All,
I have a problem related to Xserver, i have today downloaded the latest
cvs ver (http://www.freedesktop.org/~sk/xserver-inst.sh) and i have a
problem that looks like this:
http://julius.solutions-i.org/uploaded/images/xvesa.jpg
As You see some colors are not how it should be, and this is happening
only at 16bit. If i restart my xvesa in 24bit everything works fine,
just the problem is that i don't have 1400x1050 with 24bit, just with 16
so i need to chose a smaller resolution.
Thanks in advance,
Julius
From leen.toelen at cropdesign.com Wed Jun 9 04:07:28 2004
From: leen.toelen at cropdesign.com (Leen Toelen)
Date: Wed Jun 9 04:08:07 2004
Subject: [Xorg] HALification of xorg/xserver
Message-ID: <[email protected]>
Hi all,
some time ago I found some mails in the xserver list about autodetecting
video cards and getting rid of some parts of the XFree86Config file.
Recently I installed debian (unstable) and got some questions from the
XFree86 installer about refresh rates, video card type, amount of video
memory etc. Now, I am fairly knowledgable about computers, but I believe
that a normal user finds it very hard to answer these questions. Also,
when a user changes a video card, the config file needs to be adapted as
well, otherwise the xserver just won't start.
So my question: is there any work going on to halify the xorg/xserver,
and autodetecxt these settings at runtime, or is the general plan to
stick with the configuration file? It would be great if the
configuration tools just changed the hal keys, and the kernel warns hal
about the video card/mouse/keyboard present, and these are queried when
starting x.
Best regards,
Leen Toelen
confidentiality notice:
The information contained in this e-mail is confidential and may be the subject
of
legal professional privilege. It is intended for the authorized use of the indiv
idual
or entity addressed. If the receiver or reader of this message is not the intend
ed
recipient, you are hereby notified that any disclosure, copying, distribution o
r
use of the contents of this message is prohibited.
If this email is received in error, please accept our apologies, delete all copi
es
from your system, and notify us at [email protected]
From jaymz at artificial-stupidity.net Wed Jun 9 04:43:21 2004
From: jaymz at artificial-stupidity.net (Jaymz Julian)
Date: Wed Jun 9 04:43:30 2004
Subject: [Xorg] Xvesa, Xfbdev, Xchips ... wrong color palette?
In-Reply-To: <1086802922.14427.5.camel@julius>;
from [email protected] on Wed, Jun 09, 2004 at 01:42:02PM
-0400
References: <1086802922.14427.5.camel@julius>
Message-ID: <[email protected]>
On Wed, Jun 09, 2004 at 01:42:02PM -0400, P.I.Julius wrote:
> Dear All,
>
> I have a problem related to Xserver, i have today downloaded the latest
> cvs ver (http://www.freedesktop.org/~sk/xserver-inst.sh) and i have a
> problem that looks like this:
>
> http://julius.solutions-i.org/uploaded/images/xvesa.jpg
>
> As You see some colors are not how it should be, and this is happening
> only at 16bit. If i restart my xvesa in 24bit everything works fine,
> just the problem is that i don't have 1400x1050 with 24bit, just with 16
> so i need to chose a smaller resolution.
try -swaprgb
-- jay
--
--
Jaymz Julian - Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people.
Very few people have `I want to be killed and eaten' on their cards,
so Hannibal is out of a job." - http://cards.sf.net
From julius at solutions-i.org Wed Jun 9 11:51:47 2004
From: julius at solutions-i.org (P.I.Julius)
Date: Wed Jun 9 04:51:12 2004
Subject: [Xorg] Xvesa, Xfbdev, Xchips ... wrong color palette?
In-Reply-To: <[email protected]>
References: <1086802922.14427.5.camel@julius>
<[email protected]>
Message-ID: <1086807107.16110.2.camel@julius>
The same result :(
I have an Nvdidia gforce 4 if this has something to do with this, and i
used this command:
/opt/fdo/bin/Xvesa -screen 1400x1050x16 -swaprgb -2button -br :1 & xterm
-display :1 -e /root/startup
Thanks,
Julius
On Wed, 2004-06-09 at 21:43 +1000, Jaymz Julian wrote:
> On Wed, Jun 09, 2004 at 01:42:02PM -0400, P.I.Julius wrote:
> > Dear All,
> >
> > I have a problem related to Xserver, i have today downloaded the latest
> > cvs ver (http://www.freedesktop.org/~sk/xserver-inst.sh) and i have a
> > problem that looks like this:
> >
> > http://julius.solutions-i.org/uploaded/images/xvesa.jpg
> >
> > As You see some colors are not how it should be, and this is happening
> > only at 16bit. If i restart my xvesa in 24bit everything works fine,
> > just the problem is that i don't have 1400x1050 with 24bit, just with 16
> > so i need to chose a smaller resolution.
>
> try -swaprgb
>
> -- jay
>
From alan at lxorguk.ukuu.org.uk Wed Jun 9 04:36:35 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed Jun 9 05:39:42 2004
Subject: [Xorg] Making small changes to the XAA layer
Message-ID: <[email protected]>
I've been chasing a couple of bug reports in my Voodoo2 driver as well
as looking at performance problems previously. I've hit two things
where XAA doesn't "do the right thing" for the hardware
1. ColorExpandFill has no NO_GXCOPY support that I can find, unlike the
other relevant operations. This would speed Voodoo2 up a little but is a
minor item
2. When uploading image data the Voodoo2 needs to wait for the
accelerator to idle each scan line end, which also has no XAA option.
The changes seem pretty small but I'd like to be sure that whacking the
XAA layer is the right place to fix these limitations.
Alan
From michel at daenzer.net Wed Jun 9 07:53:47 2004
From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=)
Date: Wed Jun 9 07:53:53 2004
Subject: [Xorg] Making small changes to the XAA layer
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1086792827.4192.62.camel@localhost>
On Wed, 2004-06-09 at 12:36 +0100, Alan Cox wrote:
>
> 2. When uploading image data the Voodoo2 needs to wait for the
> accelerator to idle each scan line end, which also has no XAA option.
Can't you do that in the SubsequentScanline() function?
--
Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From alan at lxorguk.ukuu.org.uk Wed Jun 9 07:25:22 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed Jun 9 08:28:33 2004
Subject: [Xorg] Making small changes to the XAA layer
In-Reply-To: <1086792827.4192.62.camel@localhost>
References: <[email protected]>
<1086792827.4192.62.camel@localhost>
Message-ID: <[email protected]>
On Mer, 2004-06-09 at 15:53, Michel D?nzer wrote:
> On Wed, 2004-06-09 at 12:36 +0100, Alan Cox wrote:
> >
> > 2. When uploading image data the Voodoo2 needs to wait for the
> > accelerator to idle each scan line end, which also has no XAA option.
>
> Can't you do that in the SubsequentScanline() function?
I'd assumed the indirect method was assuming transfer to screen but you
are right. In fact since it can be filling the next buffer it may
actually be faster that way too
That just leaves the lack of NO_GXCOPY support for ColorExpandFill which
is a minor performance item at best.
From hiryu at audioseek.net Wed Jun 9 11:27:53 2004
From: hiryu at audioseek.net (Cameron)
Date: Wed Jun 9 11:15:48 2004
Subject: [Xorg] kdrive under linux 2.6
Message-ID: <[email protected]>
Hello,
I've tried running KDrive under Linux 2.6.7-rc3, 2.6.6, and 2.6.5. Perhaps
some prior releases as well.
Under every 2.6 kernel I've tried, I get a blank screen and the keyboard
doesn't respond. I am able to ssh to the machine, however, it would not soft
reboot.
I've tried Xati (I have a radeon 9800 pro), Xvesa, and Xfbdev.
Thanks.
-Cameron
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From busterbcook at yahoo.com Wed Jun 9 11:35:05 2004
From: busterbcook at yahoo.com (Brent Cook)
Date: Wed Jun 9 11:59:48 2004
Subject: [Xorg] kdrive under linux 2.6
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
It probably has something to do with your VESA bios not responding
correctly when queried for modes. I have the same issue with an entirely
unrelated video card, and traced it down to the VESA mode enumeration
function. Since almost all of the KDrive drivers use VESA for
initialization on some level, a card with a slightly-different BIOS
than the VESA routines expect causes a hang.
I still don't have a fix though, mainly due to time constraints. Once, the
VESA routines worked after several sleep/wake cycles on a laptop, as if
some random register got set to the right value, but I couldn't reproduce
it.
- Brent
On Wed, 9 Jun 2004, Cameron wrote:
> Hello,
>
> I've tried running KDrive under Linux 2.6.7-rc3, 2.6.6, and 2.6.5. Perhaps
> some prior releases as well.
>
> Under every 2.6 kernel I've tried, I get a blank screen and the keyboard
> doesn't respond. I am able to ssh to the machine, however, it would not soft
> reboot.
>
> I've tried Xati (I have a radeon 9800 pro), Xvesa, and Xfbdev.
>
> Thanks.
>
> -Cameron
>
> --
>
> "A dream to some... A NIGHTMARE TO OTHERS!"
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From breun at xs4all.nl Wed Jun 9 12:23:45 2004
From: breun at xs4all.nl (Nils Breunese)
Date: Wed Jun 9 12:23:54 2004
Subject: [Xorg] Multihead setup with "nv" and "sis" drivers
Message-ID: <[email protected]>
Hello,
I'm running Fedora Core 2 with xorg-x11 6.7.0-3 and two videocards. I
upgraded from Fedora Core 1 (which had XFree86 instead of X.org) in
which I had a dual monitor setup using two videocards: an AGP nVidia
GeForce4 MX 440 and a PCI SiS 6326 card. Because the current Fedora Core
2 kernels are incompatible with the binary drivers from nVidia, I'm
currently using the "nv" and the "sis" driver from X.org.
However, I don't seem to be able to use both monitors at the same time
anymore. When I upgraded to X.org I got an error that no screen could be
opened. After looking around in /var/log/Xorg.0.log I found maybe I had
to set a value for the PixMap Option in /etc/X11/xorg.conf, so I added
this my xorg.conf:
Section "ServerFlags"
Option "PixMap" "32"
EndSection
After adding this X would start again, but only on the nVidia display,
the monitor connected to the SiS card stayed black. After checking
/var/log/Xorg.0.log again I changed the value for the PixMap option to
24. After restarting X now I had my SiS display working, but the nVidia
display stayed black. Apparently the "nv" driver doesn't support the 24
bpp PixMap option and the "sis" driver complains about 32 bpp for
PixMap. Xorg.0.log gives me an error like this (using 32 bpp PixMap):
(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): **************************************************
Is this a bug in the X.org video drivers or is the hardware really not
capable of these PixMap values? I don't think the latter is the case as
I used to be able to use both displays under XFree86 (not setting a
value for the PixMap option at all). Or am I looking in the wrong place?
I attached my xorg.conf.
Thanks,
Nils Breunese.
--
"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
Section "ServerFlags"
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"
Load "record"
Load "freetype"
Load "speedo" # ?
Load "xtrap" # ?
Load "type1"
# Load "dri"
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
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "no"
EndSection
Section "InputDevice"
# 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 "Protocol" "IMPS/2"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5"
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
Identifier "Monitor1"
VendorName "Compaq"
ModelName "11"
HorizSync 31.5 - 37.9
VertRefresh 50.0 - 70.0
Option "dpms"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: 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" # <i>
#Option "FlatPanel" # [<bool>]
#Option "FPDither" # [<bool>]
#Option "CrtcNumber" # <i>
Identifier "Card0"
Driver "nv"
VendorName "nVidia Corporation"
BoardName "NV17 [GeForce4 MX 440]"
BusID "PCI:1:0:0"
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: 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 "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" # <i>
#Option "ForceCRT1" # [<bool>]
#Option "DSTN" # [<bool>]
#Option "XvOnCRT2" # [<bool>]
#Option "PanelDelayCompensation" # <i>
#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" # <i>
#Option "CHTVLumaBandwidthSVIDEO" # <i>
#Option "CHTVLumaFlickerFilter" # <i>
#Option "CHTVChromaBandwidth" # <i>
#Option "CHTVChromaFlickerFilter" # <i>
#Option "CHTVCVBSColor" # [<bool>]
#Option "CHTVTextEnhance" # <i>
#Option "CHTVContrast" # <i>
#Option "SISTVEdgeEnhance" # <i>
#Option "SISTVAntiFlicker" # <i>
#Option "SISTVSaturation" # <i>
#Option "TVXPosOffset" # <i>
#Option "TVYPosOffset" # <i>
#Option "SIS6326TVAntiFlicker" # <str>
#Option "SIS6326TVEnableYFilter" # [<bool>]
#Option "SIS6326TVYFilterStrong" # [<bool>]
#Option "UseColorHWCursor" # [<bool>]
#Option "ColorHWCursorBlending" # [<bool>]
#Option "ColorHWCursorBlendThreshold" # <i>
#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
SubSection "Display"
Depth 4
EndSubSection
SubSection "Display"
Depth 8
EndSubSection
SubSection "Display"
Depth 15
EndSubSection
SubSection "Display"
Depth 16
EndSubSection
SubSection "Display"
Depth 24
Modes "1152x864" "1024x768" "800x600"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Card1"
Monitor "Monitor1"
DefaultDepth 24
SubSection "Display"
Depth 1
EndSubSection
SubSection "Display"
Depth 4
EndSubSection
SubSection "Display"
Depth 8
EndSubSection
SubSection "Display"
Depth 15
EndSubSection
SubSection "Display"
Depth 16
EndSubSection
SubSection "Display"
Depth 24
Modes "1024x768" "800x600"
EndSubSection
EndSection
Section "DRI"
Group 0
Mode 0666
EndSection
From c_mertes at t-online.de Wed Jun 9 14:05:42 2004
From: c_mertes at t-online.de (Christian Mertes)
Date: Wed Jun 9 14:06:07 2004
Subject: [Xorg] German Dvorak Layout for Xkb and Greek Letters Extension
Message-ID: <20040609230542.1b57b912@Gaston>
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040609/e69e274c/attach
ment.pgp
From spamfrommailing at freax.org Wed Jun 9 14:37:18 2004
From: spamfrommailing at freax.org (Philip Van Hoof)
Date: Wed Jun 9 14:37:22 2004
Subject: [Xorg] Switching from dual to singlehead and technical documentation
Message-ID: <1086817038.5530.18.camel@pluisje>
Hi there,
For many typical presentation purposes, it would be very useful to have
a tool to enable and disable dual-head (and xinerama) configs on the
fly.
I often find myself in a situation where I want to enable or disable the
dual-head setting of my x-server while not being 'okay' with the fact
that this means restarting all my desktop applications (because, of
course, they will stop with the restarting of my xserver).
As a developer I am willingness to help if somebody is putting efforts
in getting this supported or writing tools that enable people to do
this. I don't have enough experience with the huge code of Xorg or
whatever component that would be responsible for this to start
developing this on my very own. It would take me days just to know where
to start. That's not very productive of course.
That brings me to another proposal:
To start writing technical documentation about the Xorg implementation.
Much like the "Inside the Linux kernel"-book published by O'Reilly. IMHO
such documentation would have got people like me -who are frustrated
enough about such issues that they want to learn how to fix it- going.
My real humble opinion on this is that an organisation (like
freedesktop.org or like the Linux Documentation Project) should start
creating high level technical documentation about the important pieces
of our opensource operating system/environment (being Mozilla, the Xorg
xserver stuff, GNOME and GTK+, KDE and Qt, softwares like Evolution and
OpenOffice.org and of course the kernel -which has already pretty much
sources of high level technical documentation, even a kernelnewbies
website and IRC Channel-).
Again I am willingness to help and again I don't have enough experience
to start doing this all by myself. It's probably because I don't have
that experience with these components, that I am greedy for such
documentation (hence my reason for asking). I do want to help all these
exciting projects, and I probably am talented enough to help. I just
don't want to loose the rest of my life reading through huge
repositories of code.
--
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org
From dougmc83 at mail.utexas.edu Wed Jun 9 14:50:46 2004
From: dougmc83 at mail.utexas.edu (Douglas McMorris)
Date: Wed Jun 9 14:50:49 2004
Subject: [Xorg] Flash player plugin and Xserver
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Yep, that fixed my problem, thanks Keith.
On Mon, 2004-06-07 at 16:28 -0700, Keith Packard wrote:
> Around 17 o'clock on Jun 7, Douglas McMorris wrote:
>
> > I can't get the flashplayer plugin from macromedia work with the kdrive
> > Xserver. Not sure whats going on, but heres the error I get... (note:
> > same problem in mozilla... i just use epiphany)
>
> You've got to hide the non-default visuals from flash -- it appears to
> assume the visual used for its window is the deepest available visual
> instead of actually checking.
>
> I've got a kludge in Xlib that I'm using to make flash and mozilla always
> use the default visual (by removing all others from view). Enable it
> with:
>
> $ XLIB_SKIP_EXTRA_VISUALS=yes mozilla
>
> Yes, flash is broken. But then, mozilla is pretty nasty as well -- it
> selects my depth 24 visual now that I have one even though the root window
> is depth 16. Fun with visuals!
>
> -keith
>
> Index: src/OpenDis.c
> ===================================================================
> RCS file: /cvs/xlibs/X11/src/OpenDis.c,v
> retrieving revision 3.22
> diff -u -r3.22 OpenDis.c
> --- a/src/OpenDis.c 17 Mar 2004 18:06:35 -0000 3.22
> +++ b/src/OpenDis.c 7 Jun 2004 23:26:27 -0000
> @@ -596,6 +596,13 @@
> u.vp = (xVisualType *) (((char *) u.vp) +
> sz_xVisualType);
> }
> + if (dp->depth != sp->root_depth &&
> + getenv ("XLIB_SKIP_EXTRA_VISUALS"))
> + {
> + Xfree (dp->visuals);
> + dp->visuals = NULL;
> + dp->nvisuals = 0;
> + }
> } else {
> dp->visuals = (Visual *) NULL;
> }
>
From vitorio at digitel.com.br Wed Jun 9 19:19:58 2004
From: vitorio at digitel.com.br (=?ISO-8859-1?Q?Lu=EDs_Vit=F3rio?= Cargnini)
Date: Wed Jun 9 15:37:44 2004
Subject: [Xorg] XkbRules
Message-ID: <[email protected]>
Hi,
In XFree86 we must use XkbRules "xfree86" to could use keys like "? ? ;
/ ^] ? ? `" because we are using keyboards abnt-2 (when i say we i
mention the person from Brasil like me).
But in Xorg i trying the XkbRules "xorg" and the results is that my key
"?" for example isn't working.
System:
FreeBSD 5.2.1-p8
Xorg - FluxBox
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://freedesktop.org/pipermail/xorg/attachments/20040609/d5c12b1f/attach
ment.pgp
From agd5f at yahoo.com Wed Jun 9 16:06:16 2004
From: agd5f at yahoo.com (Alex Deucher)
Date: Wed Jun 9 16:06:48 2004
Subject: [Xorg] Switching from dual to singlehead and technical
documentation
In-Reply-To: <1086817038.5530.18.camel@pluisje>
Message-ID: <[email protected]>
--- Philip Van Hoof <[email protected]> wrote:
>
> Hi there,
>
>
> For many typical presentation purposes, it would be very useful to
> have
> a tool to enable and disable dual-head (and xinerama) configs on the
> fly.
>
you can do that to a certain degree with MergedFB and xrandr. start X
with mergedfb set to a dualheaded desktop, then you can resize it on
the fly with xrandr assuming you've specified clone modes in your
config. MergedFB is available for radeon in DRI cvs, and for sis in
all xfree86 derived trees.
> I often find myself in a situation where I want to enable or disable
> the
> dual-head setting of my x-server while not being 'okay' with the fact
> that this means restarting all my desktop applications (because, of
> course, they will stop with the restarting of my xserver).
>
> As a developer I am willingness to help if somebody is putting
> efforts
> in getting this supported or writing tools that enable people to do
> this. I don't have enough experience with the huge code of Xorg or
> whatever component that would be responsible for this to start
> developing this on my very own. It would take me days just to know
> where
> to start. That's not very productive of course.
Right now we have to decide, in the restructured xserver, which parts
will live where (user vs. kernel), then we can implement a more dyanmic
system on top of it.
Alex
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From rafael.espindola at ic.unicamp.br Fri Jun 11 12:04:45 2004
From: rafael.espindola at ic.unicamp.br (Rafael =?iso-8859-1?q?=C1vila_de_Esp=ED
ndola?=)
Date: Fri Jun 11 12:02:19 2004
Subject: [Xorg] Bug 515
Message-ID: <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hy,
Could some one comment/fix the bug 515? There is a simple patch that solves
the problem at http://freedesktop.org/bugzilla/show_bug.cgi?id=515
Thanks.
Rafael ?vila de Esp?ndola
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAyRNCLlrfGJ8JUHwRArhAAKDYhHL3mIs/FdCh04oa2gYH0fakBwCfdxW2
zVHaplouhLcxz5clXuattIk=
=eIcB
-----END PGP SIGNATURE-----
From Alan.Coopersmith at Sun.COM Fri Jun 11 18:14:21 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Fri Jun 11 18:13:25 2004
Subject: [Xorg] Bug 515
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Rafael ?vila de Esp?ndola wrote:
> Could some one comment/fix the bug 515? There is a simple patch that solves
> the problem at http://freedesktop.org/bugzilla/show_bug.cgi?id=515
There was a recent announcement of a project set up on freedesktop.org to
maintain the XKB database files - are they going to be handling bugs like this?
Should such bugs should be assigned to an alias for the people working on that
project?
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From alan at lxorguk.ukuu.org.uk Sat Jun 12 03:25:59 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sat Jun 12 04:29:10 2004
Subject: [Xorg] Making small changes to the XAA layer
In-Reply-To: <[email protected]>
References: <[email protected]>
<1086792827.4192.62.camel@localhost>
<[email protected]>
Message-ID: <[email protected]>
> > Can't you do that in the SubsequentScanline() function?
>
> I'd assumed the indirect method was assuming transfer to screen but you
> are right. In fact since it can be filling the next buffer it may
> actually be faster that way too
Ok updated Voodoo driver posted to
ftp://people.redhat.com/alan/XFree86
This fixes the various bugs I've had reported along the way and
switches to the Scanline functions. I've labelled it "1.0" since I think
its now happily post-beta
Alan
From eta at lclark.edu Sat Jun 12 16:15:22 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sat Jun 12 16:15:57 2004
Subject: [Xorg] New committer process?
Message-ID: <1087020922.86211.49.camel@leguin>
What is the process for bringing new committers in, or do we have one
yet? Would it be OK for existing committers to sponsor new ones, or
should there be some sort of approval?
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From eta at lclark.edu Sat Jun 12 16:17:12 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sat Jun 12 16:17:45 2004
Subject: [Xorg] DRI merging
Message-ID: <1087021032.86211.53.camel@leguin>
I would like to see a merge from DRI CVS to X.Org in the near future.
Is there any opposition to this?
I could allocate the time to do it myself, I think, though my CVS skills
aren't too great. If I were to do it, I'd just take from head. While
it's an in-development branch, we could slurp patches over pretty easily
since afaik we don't have a release coming up in the next month. This
would involve bringing in an import of Mesa 6. The DRI drivers
currently in the tree would become Imakefile glue for the drivers that
are in Mesa 6.
Talking with daniels on irc, I understand there might be license
concerns floating around. DRI CVS hasn't had a merge from XFree86 since
4.3.99.12, which was before the license changes.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From michel at daenzer.net Sat Jun 12 07:44:43 2004
From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=)
Date: Sat Jun 12 07:44:51 2004
Subject: [Xorg] DRI merging
In-Reply-To: <1087021032.86211.53.camel@leguin>
References: <1087021032.86211.53.camel@leguin>
Message-ID: <1087051483.4193.169.camel@localhost>
On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote:
> I would like to see a merge from DRI CVS to X.Org in the near future.
> Is there any opposition to this?
No opposition, but a concern: Where are we going to integrate the DRI
with the Composite extension, in the X.Org or DRI tree? I'd be in favour
of moving the DRI tree to a branch of the X.Org tree altogether, but I'd
like to hear what other people's current opinions are on this.
> Talking with daniels on irc, I understand there might be license
> concerns floating around. DRI CVS hasn't had a merge from XFree86 since
> 4.3.99.12, which was before the license changes.
Yeah, I've always voiced my opinion against infecting the DRI tree with
the new XFree86 licence. I don't know about the X-Oz licence though.
--
Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From alexdeucher at gmail.com Sat Jun 12 08:40:42 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Sat Jun 12 08:40:48 2004
Subject: [Xorg] DRI merging
In-Reply-To: <1087051483.4193.169.camel@localhost>
References: <1087021032.86211.53.camel@leguin>
<1087051483.4193.169.camel@localhost>
Message-ID: <[email protected]>
On Sat, 12 Jun 2004 16:44:43 +0200, Michel D?nzer <[email protected]> wrote:
>
> On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote:
> > I would like to see a merge from DRI CVS to X.Org in the near future.
> > Is there any opposition to this?
>
> No opposition, but a concern: Where are we going to integrate the DRI
> with the Composite extension, in the X.Org or DRI tree? I'd be in favour
> of moving the DRI tree to a branch of the X.Org tree altogether, but I'd
> like to hear what other people's current opinions are on this.
I agree. While we are on the subject, there are also two big patches
that ought to be merged at some point which could make the merge from
the DRI somewhat more complicated. The first is Ati's new radeon code
drop (with revamped crtc handling, r4xx suppot, and render accel) and
the second is the new intel DDX. since the intel driver now supports
multi-head and ryan's latest work removes the hallib requirements from
the matrox driver, it might be a good time to decide how to proceed
with mergedfb. right now it's all DDX specific code, but most of it
could be made generic, which would make it easier to support mergedfb
in all the drivers that currently support dualhead (intel, matrox,
sis, radeon, etc.). Doing this may, however, affect compatibility
with xfree86 unless they picked up the patches.
>
>
> > Talking with daniels on irc, I understand there might be license
> > concerns floating around. DRI CVS hasn't had a merge from XFree86 since
> > 4.3.99.12, which was before the license changes.
>
> Yeah, I've always voiced my opinion against infecting the DRI tree with
> the new XFree86 licence. I don't know about the X-Oz licence though.
I'd rather not mess with that either.
>
> --
> Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
> Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
>
From eta at lclark.edu Sat Jun 12 10:45:50 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sat Jun 12 10:46:35 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <1087021032.86211.53.camel@leguin>
<1087051483.4193.169.camel@localhost>
<[email protected]>
Message-ID: <1087062350.81204.68.camel@leguin>
On Sat, 2004-06-12 at 08:40, Alex Deucher wrote:
> On Sat, 12 Jun 2004 16:44:43 +0200, Michel D?nzer <[email protected]> wrote:
> >
> > On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote:
> > > I would like to see a merge from DRI CVS to X.Org in the near future.
> > > Is there any opposition to this?
> >
> > No opposition, but a concern: Where are we going to integrate the DRI
> > with the Composite extension, in the X.Org or DRI tree? I'd be in favour
> > of moving the DRI tree to a branch of the X.Org tree altogether, but I'd
> > like to hear what other people's current opinions are on this.
>
> I agree. While we are on the subject, there are also two big patches
> that ought to be merged at some point which could make the merge from
> the DRI somewhat more complicated. The first is Ati's new radeon code
> drop (with revamped crtc handling, r4xx suppot, and render accel) and
> the second is the new intel DDX. since the intel driver now supports
> multi-head and ryan's latest work removes the hallib requirements from
> the matrox driver, it might be a good time to decide how to proceed
> with mergedfb. right now it's all DDX specific code, but most of it
> could be made generic, which would make it easier to support mergedfb
> in all the drivers that currently support dualhead (intel, matrox,
> sis, radeon, etc.). Doing this may, however, affect compatibility
> with xfree86 unless they picked up the patches.
I'm working on the Render acceleration -- there were some conformance
issues in the ATI patch that I'm working on fixing, along with making it
more featureful.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From eta at lclark.edu Sat Jun 12 10:47:07 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sat Jun 12 10:47:54 2004
Subject: [Xorg] DRI merging
In-Reply-To: <1087051483.4193.169.camel@localhost>
References: <1087021032.86211.53.camel@leguin>
<1087051483.4193.169.camel@localhost>
Message-ID: <1087062427.81204.72.camel@leguin>
On Sat, 2004-06-12 at 07:44, Michel D?nzer wrote:
> On Fri, 2004-06-11 at 23:17 -0700, Eric Anholt wrote:
> > I would like to see a merge from DRI CVS to X.Org in the near future.
> > Is there any opposition to this?
>
> No opposition, but a concern: Where are we going to integrate the DRI
> with the Composite extension, in the X.Org or DRI tree? I'd be in favour
> of moving the DRI tree to a branch of the X.Org tree altogether, but I'd
> like to hear what other people's current opinions are on this.
I was hoping that DRI work on pbuffers might go quickly and have the
drivers ready for rendering to targets besides the screen, which is what
we really need for Composite support. The other thing would be Damage,
but that'll be easy I think. I assume this would be done in the tree
where Composite gets integrated first, but again, I don't expect it to
be too hard if we can render to other targets.
I am definitely in favor of the DRI X tree stuff being a branch on the
X.Org tree.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From svu at gnome.org Sat Jun 12 11:08:41 2004
From: svu at gnome.org (Sergey V. Udaltsov)
Date: Sat Jun 12 11:08:57 2004
Subject: [Xorg] ANNOUNCE: xkeyboard-config 0.2
Message-ID: <1087063721.3604.50.camel@sputnik>
The XKeyboardConfig project holds its promise to "release often" - and
delivers the second version, 0.2.
Tha major thing in this release is the document (docs/HOWTO.transition)
briefly describing the process of using XKeyboardConfig database instead
of the one shipped with the server (XFree86/X.Org). Also, to help with
this, the xkbcomp symlink autocreation (optional, enabled by default)
was implemented. Now, everyone can really try this database and
complain, send bugs etc.
We express our gratitude to John C Barstow, who sent us the patch for
the new Maori layout - it is included.
Also, thanks to Rafael ?vila de Esp?ndola who fixed the bug #515
(freedesktop.org CVS) related to the Brasilian layout - the fix made its
way to this release.
The tarball (~700K) can be download from the standard place:
http://freedesktop.org/~xlibs/release/xkeyboard-config-0.2.tar.gz
Cheers,
Sergey
From jonsmirl at yahoo.com Sat Jun 12 19:07:47 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sat Jun 12 19:07:49 2004
Subject: [Xorg] DRI merging
In-Reply-To: <1087062350.81204.68.camel@leguin>
Message-ID: <[email protected]>
Why not help getting mesa-solo working so that we can move to X on top of
OpenGL? Keithp is hard at work converting xserver to run on OpenGL. We already
have the render engine on top of of OpenGL finished in the glitz project. All we
are missing is pbuffer support in the mesa hw drivers and some support for
multi-head mode setting. In the xserver on OpenGL model XAA disappears.
--- Eric Anholt <[email protected]> wrote:
> I'm working on the Render acceleration -- there were some conformance
> issues in the ATI patch that I'm working on fixing, along with making it
> more featureful.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From Alan.Coopersmith at Sun.COM Sat Jun 12 19:51:02 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Sat Jun 12 19:50:34 2004
Subject: [xkb] Re: [Xorg] Bug 515
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Sergey V. Udaltsov wrote:
>>Should such bugs should be assigned to an alias for
>
> the people working
>
>>on that
>>project?
>
> It would be really nice.
Do you want that to be [email protected] or some other alias so
that bugzilla noise doesn't fill your main alias? There's a number
of other XKB config file bugs open already and another just came in:
Romanian keyboard layout is broken in xorg-x11
http://freedesktop.org/bugzilla/show_bug.cgi?id=371
Can't use the "Win" keys for PC104+ keyboards
http://freedesktop.org/bugzilla/show_bug.cgi?id=587
Keymapping for MS natural USB keyboard
http://freedesktop.org/bugzilla/show_bug.cgi?id=320
Enhanced symbols file for new keyboard
http://freedesktop.org/bugzilla/show_bug.cgi?id=326
us_intl layout maps apostrophe and quotedbl incorrectly
http://freedesktop.org/bugzilla/show_bug.cgi?id=365
The Iranian keyboard mistakenly labeled "Farsi"
http://freedesktop.org/bugzilla/show_bug.cgi?id=458
Patch, which improves lithuanian keyboard symbols file
http://freedesktop.org/bugzilla/show_bug.cgi?id=574
inet keys' keycodes not set by xkbcomp and some keyboards missing from symbols/i
net
http://freedesktop.org/bugzilla/show_bug.cgi?id=630
logicdit symbol definitions missing from /usr/X11R6/lib/X11/xkb configuration fi
les
http://freedesktop.org/bugzilla/show_bug.cgi?id=657
New XKB option for Tux keys: request for addition
http://freedesktop.org/bugzilla/show_bug.cgi?id=666
a small fix for armenian keyboard layouts
http://freedesktop.org/bugzilla/show_bug.cgi?id=743
Add multimedia keys support for A4Tech KB-21 keyboard
http://freedesktop.org/bugzilla/show_bug.cgi?id=744
XKB definitions for a Gyration Compact Keyboard (multimedia)
http://freedesktop.org/bugzilla/show_bug.cgi?id=496
XKB definitions for Super Power Internet Keyboard
http://freedesktop.org/bugzilla/show_bug.cgi?id=711
Pipe-key not working under xorg with German layout
http://freedesktop.org/bugzilla/show_bug.cgi?id=463
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From eta at lclark.edu Sat Jun 12 21:49:07 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sat Jun 12 21:49:42 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1087102146.853.9.camel@leguin>
On Sat, 2004-06-12 at 19:07, Jon Smirl wrote:
> Why not help getting mesa-solo working so that we can move to X on top of
> OpenGL? Keithp is hard at work converting xserver to run on OpenGL. We already
> have the render engine on top of of OpenGL finished in the glitz project. All
we
> are missing is pbuffer support in the mesa hw drivers and some support for
> multi-head mode setting. In the xserver on OpenGL model XAA disappears.
>
> --- Eric Anholt <[email protected]> wrote:
> > I'm working on the Render acceleration -- there were some conformance
> > issues in the ATI patch that I'm working on fixing, along with making it
> > more featureful.
As far as I understood, Mesa-solo required the linux framebuffer, which
I don't have. I seriously don't want to be the one to start work on the
mode-setting library. As far as pbuffers, once we've got the glue
necessray I'll fix up the SiS driver for it, which should be quick. But
all of this will take time to be done, and they aren't areas I've
already worked in. Render, now, I should be able to fix this patch up
in another day or maybe two, and make myself and normal users happy in
the short term.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From jonsmirl at yahoo.com Sat Jun 12 22:55:24 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sat Jun 12 22:55:29 2004
Subject: [Xorg] DRI merging
In-Reply-To: <1087102146.853.9.camel@leguin>
Message-ID: <[email protected]>
--- Eric Anholt <[email protected]> wrote:
> As far as I understood, Mesa-solo required the linux framebuffer, which
> I don't have. I seriously don't want to be the one to start work on the
> mode-setting library. As far as pbuffers, once we've got the glue
> necessray I'll fix up the SiS driver for it, which should be quick. But
> all of this will take time to be done, and they aren't areas I've
> already worked in. Render, now, I should be able to fix this patch up
> in another day or maybe two, and make myself and normal users happy in
> the short term.
I added mode setting support to DRM while you were gone. That caused a big stink
and it is not in there now. There is a meeting scheduled at OLS to discuss the
issues between DRM and fbdev.
The complicated part of mode setting is what do you do when there are multiple
heads involved? If multiple head mode setting stays in fbdev then fbdev needs to
do memory management but DRM does complicated memory management that is not in
fbdev.
Another large point of contention is whether mode setting should be done
completely in the kernel including DDC support. The alternate solution is to
read DDC from user space and compute the mode info there. Then just pass the
final register values into the driver.
I also added a hot plug event to DRM to trigger a user space reset program than
ran in vm86 mode, but that's been pulled too. Read the dri-devel and fbdev mail
archives, there are hundreds of messages on this subject. Other topics that were
discussed included printk with DRM and rework of the kernel VT subsystem.
If I could get reset, mode setting, and cursor support into DRM mesa-solo
wouldn't need framebuffer anymore.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From msipkema at sipkema-digital.com Sun Jun 13 05:31:12 2004
From: msipkema at sipkema-digital.com (Martijn Sipkema)
Date: Sun Jun 13 04:31:39 2004
Subject: [Xorg] DRI merging
References: <[email protected]>
Message-ID: <004101c45142$506bccf0$161b14ac@boromir>
> Why not help getting mesa-solo working so that we can move to X on top of
> OpenGL?
Where can I find more information about mesa-solo? Is this the same as
miniglx?
> Keithp is hard at work converting xserver to run on OpenGL. We already
> have the render engine on top of of OpenGL finished in the glitz project.
All we
> are missing is pbuffer support in the mesa hw drivers and some support for
> multi-head mode setting. In the xserver on OpenGL model XAA disappears.
Does mesa-solo handle multiple rendering surfaces or just a single redering
surface that is the whole framebuffer? Are multiple visuals supported?
--ms
From kde at myrealbox.com Sun Jun 13 06:57:13 2004
From: kde at myrealbox.com (ismail donmez)
Date: Sun Jun 13 06:56:18 2004
Subject: [Xorg] Adding support for A4Tech KB-21 keyboard multimedia keys
Message-ID: <[email protected]>
Hi all,
I created 3 small patches adding support for A4Tech KB-21 keyboard's
multimedia keys. Please check
http://freedesktop.org/bugzilla/show_bug.cgi?id=744 for details.
Cheers,
/ismail d?nmez
--
Time is what you make of it.
From alan at lxorguk.ukuu.org.uk Sun Jun 13 06:53:02 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 07:56:16 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
> Why not help getting mesa-solo working so that we can move to X on top of
> OpenGL?
For one, in the two years that is going to take to bear fruit, we need a
working X server. Two because mesa-solo isnt supported on most of
the Xorg platforms.
Alan
From jonsmirl at yahoo.com Sun Jun 13 08:19:07 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 08:19:10 2004
Subject: [Xorg] DRI merging
In-Reply-To: <004101c45142$506bccf0$161b14ac@boromir>
Message-ID: <[email protected]>
--- Martijn Sipkema <[email protected]> wrote:
> > Why not help getting mesa-solo working so that we can move to X on top of
> > OpenGL?
>
> Where can I find more information about mesa-solo? Is this the same as
> miniglx?
Same thing. http://mesa3d.sourceforge.net/fbdev-dri.html
>
> > Keithp is hard at work converting xserver to run on OpenGL. We already
> > have the render engine on top of of OpenGL finished in the glitz project.
> All we
> > are missing is pbuffer support in the mesa hw drivers and some support for
> > multi-head mode setting. In the xserver on OpenGL model XAA disappears.
>
> Does mesa-solo handle multiple rendering surfaces or just a single redering
> surface that is the whole framebuffer? Are multiple visuals supported?
This is a work in progress. mesa-solo is the same code as DRI. Any DRI features
should work in mesa-solo provided the needed code has been made to work in the
solo environment.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From jonsmirl at yahoo.com Sun Jun 13 08:34:46 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 08:34:48 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Alan Cox <[email protected]> wrote:
> On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
> > Why not help getting mesa-solo working so that we can move to X on top of
> > OpenGL?
>
> For one, in the two years that is going to take to bear fruit, we need a
> working X server. Two because mesa-solo isnt supported on most of
> the Xorg platforms.
The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
get to work on a response. Getting mesa-solo running everywhere wouldn't take
two years if more people would pitch in and quit arguing. Right now we should
have a working xserver/mesa-solo this summer, even sooner if there was more
help.
I'm not sure if you mean platforms as in OS or platform as in cards, but
mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the
accelerated drivers that covers all of the more common hardware.
All of the pieces needed to get xserver running on mesa already exist; all we
need to do is pull everything together. xserver on GL is an architecture that
will be good for at least another ten years while the current XAA architecture
is close to the end of it's life.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From Alan.Coopersmith at Sun.COM Sun Jun 13 09:25:54 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Sun Jun 13 09:24:55 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Jon Smirl wrote:
> --- Alan Cox <[email protected]> wrote:
>
>>On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
>>
>>>Why not help getting mesa-solo working so that we can move to X on top of
>>>OpenGL?
>>
>>For one, in the two years that is going to take to bear fruit, we need a
>>working X server. Two because mesa-solo isnt supported on most of
>>the Xorg platforms.
>
> I'm not sure if you mean platforms as in OS or platform as in cards, but
> mesa-solo runs on the fbdev driver using software mesa. Between fbdev and the
> accelerated drivers that covers all of the more common hardware.
But fbdev only covers one of the supported OS'es right? Xorg runs on the BSD's,
Solaris, Windows/Cygwin, MacOS X, and many other platforms without fbdev, so it'
s
very premature to say that work on anything else is wasted.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From roland.mainz at nrubsig.org Sun Jun 13 10:28:53 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Sun Jun 13 10:29:14 2004
Subject: [Xorg] DRI merging
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alan Coopersmith wrote:
> >>>Why not help getting mesa-solo working so that we can move to X on top of
> >>>OpenGL?
> >>
> >>For one, in the two years that is going to take to bear fruit, we need a
> >>working X server. Two because mesa-solo isnt supported on most of
> >>the Xorg platforms.
> >
> > I'm not sure if you mean platforms as in OS or platform as in cards, but
> > mesa-solo runs on the fbdev driver using software mesa. Between fbdev and th
e
> > accelerated drivers that covers all of the more common hardware.
>
> But fbdev only covers one of the supported OS'es right? Xorg runs on the BSD'
s,
> Solaris, Windows/Cygwin, MacOS X,
... HP-UX, IRIX, BeOS, AIX etc ...
> and many other platforms without fbdev, so it's
> very premature to say that work on anything else is wasted.
I agree with Alan.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From braun at club-internet.fr Sun Jun 13 10:37:03 2004
From: braun at club-internet.fr (Damien Ciabrini)
Date: Sun Jun 13 10:36:59 2004
Subject: [Xorg] new kdrive patch for 32bpp support and hw composition
Message-ID: <[email protected]>
Hi all,
Following my previous posts, I've finally got time to do a new patch for
supporting the matrox g4xx cards into kdrive.
This patch adds a proper support for 32bpp modes. It also fixes a race
condition between the gfxcard and the processor that exists in the original
mga driver.
Like the old patch, it allows to do HW alpha blending. It benefits from the
two texture units of the g4xx.
I ran tests with the server in 32bpp with aewm, fdclock and xcompmgr.
Everything seems to work correctly.
Jaymz (Julian), maybe you could test this patch with your hardware ?
Also, I'd like to know if it would be possible to merge my patches into the
kdrive CVS ? I think it's desirable, since nobody seems to maintain this
driver anymore. I don't know whom I must ask for this ?
Regards,
Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xserver-mga-composite-and-32bpp-support.patch.gz
Type: application/x-gzip
Size: 6689 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040613/dc3db40a/xserve
r-mga-composite-and-32bpp-support.patch-0001.bin
From alan at lxorguk.ukuu.org.uk Sun Jun 13 09:42:42 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 10:45:51 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 16:34, Jon Smirl wrote:
> The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
> get to work on a response. Getting mesa-solo running everywhere wouldn't take
> two years if more people would pitch in and quit arguing. Right now we should
> have a working xserver/mesa-solo this summer, even sooner if there was more
> help.
This isn't relevant to the Xorg server.
> need to do is pull everything together. xserver on GL is an architecture that
> will be good for at least another ten years while the current XAA architecture
> is close to the end of it's life.
You have no solution to non 3D heavy cards, you have no solution to
non-Linux hardware platforms. Most of your linux ideas have been thrown
out repeatedly as half-baked on multiple lists.
mesa-solo is a *research* project. If it works out then in two years
time its going to be rather cool. In the mean time trying to stop people
doing important work to cripple what you perceive as a rival is just
wrong.
From jonsmirl at yahoo.com Sun Jun 13 12:13:43 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 12:13:45 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Alan Cox <[email protected]> wrote:
> You have no solution to non 3D heavy cards, you have no solution to
> non-Linux hardware platforms. Most of your linux ideas have been thrown
> out repeatedly as half-baked on multiple lists.
>
> mesa-solo is a *research* project. If it works out then in two years
> time its going to be rather cool. In the mean time trying to stop people
> doing important work to cripple what you perceive as a rival is just
> wrong.
I don't know why I continue to waste my time on this project. The MS Longhorn UI
is clearly a generation better than anything available on Linux. Right now Linux
is starting to get a foothold on the desktop. All of the desktop effort will be
wasted if Linux has an obviously inferior UI for several years and Linux's
desktop acceptance backslides during that period. Of course things might easily
go the other way if Linux beats or ties MS's GUI efforts.
So if my ideas are so bad, why don't you propose your own solution to the
Longhorn problem? I have no attachment to anything I've proposed, I'll work on
any solution that solves the main problem.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From torgeir at pobox.com Sun Jun 13 12:20:54 2004
From: torgeir at pobox.com (Torgeir Veimo)
Date: Sun Jun 13 12:21:02 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alan Cox wrote:
>On Sul, 2004-06-13 at 16:34, Jon Smirl wrote:
>
>
>>The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
>>get to work on a response. Getting mesa-solo running everywhere wouldn't take
>>two years if more people would pitch in and quit arguing. Right now we should
>>have a working xserver/mesa-solo this summer, even sooner if there was more
>>help.
>>
>>
>
>This isn't relevant to the Xorg server.
>
>
>
>>need to do is pull everything together. xserver on GL is an architecture that
>>will be good for at least another ten years while the current XAA architecture
>>is close to the end of it's life.
>>
>>
>
>You have no solution to non 3D heavy cards, you have no solution to
>non-Linux hardware platforms. Most of your linux ideas have been thrown
>out repeatedly as half-baked on multiple lists.
>
>
At least he is trying. There's no need for bashing people who try to
implement new ideas.
--
-Torgeir
From jonsmirl at yahoo.com Sun Jun 13 12:25:16 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 12:25:19 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Ely Levy <[email protected]> wrote:
> If it's like you say why not pick up the glove and
> create a tree for it?
> orginize a tree with a workplan I'm sure most people would be happy to
> contribute, I know I would.
The work is already underway:
mesa-solo is here: http://mesa3d.sourceforge.net/fbdev-dri.html
xserver is here: http://www.freedesktop.org/Software/xserver
glitx is here: http://www.freedesktop.org/Software/glitz
mesa-solo - provides a standalone OpenGL environment without the need for X.
mesa-solo has 3D hardware acceleration for the same cards as DRI. For non-3D
cards it uses software mesa to write to the framebuffer.
xserver - keithp's next generation X server. It know about things like alpha
blending natively.
glitz - an implementation of the Cairo API on OpenGL. Glitz has also implemented
the X render engine in OpenGL. keithp is in the middle of adding the the OpenGL
render engine to xserver.
The basic idea is, you start with a standalone OpenGL stack. OpenGL is a high
level API with lots of room for future hardware improvement. The OpenGL stack
may either be the freedesktop one or one from Nvidia/ATI.
On top of that runs xserver. xserver does all of it's drawing via OpenGL. This
means everything will be accelerated. Remote X, xft, etc are still there -
xserver is just a variation of XFree86 with XAA removed. xlib still works,
xserver just uses OpenGL to do the drawing.
Cario/Glitz is the next layer. xserver exposes the OpenGL layer in the same way
DRI works. Glitz is written to use OpenGL in a fully accelerated, direct
rendered environment. It will also work remotely.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From jonsmirl at yahoo.com Sun Jun 13 12:35:20 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 12:35:22 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Alan Coopersmith <[email protected]> wrote:
> But fbdev only covers one of the supported OS'es right? Xorg runs on the
> BSD's, Solaris, Windows/Cygwin, MacOS X, and many other platforms without
fbdev, so
> it's very premature to say that work on anything else is wasted.
The work that would be wasted is extending the XAA 2D drivers to use the 3D
hardware to accelerate render.
fbdev dependence is a very small part of mesa-solo that I would like to remove.
fbdev is only used to set the video mode and control the cursor. Both of these
of done in user space in the current XFree XAA drivers.
There are three main solutions to mode/cursors problem that no one can agree on:
1) leave fbdev in charge of mode setting and cursor, port it around to other
architectures.
2) copy of the user space code from XFree86 into a standalone library - now you
have to be root to play with the chip.
3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the
work as possible in user space and just pass final register values to the
IOCTLs.
I would like to see #3. I have implemented #3 locally for the radeon but there
is no acceptance for adding it to main DRM drivers.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From alan at lxorguk.ukuu.org.uk Sun Jun 13 11:57:13 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 13:00:23 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 20:35, Jon Smirl wrote:
> The work that would be wasted is extending the XAA 2D drivers to use the 3D
> hardware to accelerate render.
Lots of hardware can do render without 3D operations. Even my
TV capture/playback card has blit-with-alpha on it. Extending existing
XAA drivers to do render better via DRI may make sense in some cases and
in shorter than two years.
As it is everyone is having to merge DRI and Xorg themselves right now
to get a working useful tree for 2D and 3D. Getting all the code in the
right places makes that work a lot easier, and means for example I can
viably attack S3virge and SiS6326 support. (Which you'll want for
mesa-solo eventually if only to understand the limits of hardware with
only primitive 3D support).
> There are three main solutions to mode/cursors problem that no one can agree o
n:
> 1) leave fbdev in charge of mode setting and cursor, port it around to other
> architectures.
For Linux I think everyone has accepted that you have to have a basic
fb driver simply to do hotplug. Xorg however has to run everywhere.
> 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the
> work as possible in user space and just pass final register values to the
> IOCTLs.
DRM supports two platforms of the entire X world. In most of the
proprietary cases the frame buffer layer is vendor controlled and may or
may not be doing this. I guess Alan Coopersmith can comment on this for
Solaris x86 for example.
From alan at lxorguk.ukuu.org.uk Sun Jun 13 12:04:10 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 13:07:21 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 20:47, Matt Sealey wrote:
> Linux basically falls behind on two simple fronts at the moment:
> it has no "simple" 2D or 3D framework capable of much more than
I deal with embedded Linux people on a daily basis. I think they would
disagree. For 2D it has several in heavy use
- Keith's tiny X server work
- Nanogui (2D down to about 50K RAM)
- DirectFB (particularly strong at multimedia)
For 3D you end up looking back at the mesa-solo work and it shares that
same interest with the X over mesa people.
> We need a low-level "kernel" graphics API (much like Windows
Unfortunately for a lot of hardware the entire design is different per
card. You have to deal with an incredible range of hardware and its a
tribute to the X DDX and XAA design how well it has coped with this.
I've dealt with very little that X couldn't take a good shot at handling
well. YUV422 only framebuffers being the one that gave it serious
hiccups.
Secondly every line of code you put in the kernel has to be audited,
analysed and can introduce security holes or crash the machine. Its
harder to debug and its harder to write in the first place. There are
very good reasons (see the original DRI paper) for putting as much as
you can in user space. The Mesa X work also tries to keep as much as
possible in user space - including designs for mode computation by
kernel->user callback.
From alan at lxorguk.ukuu.org.uk Sun Jun 13 12:07:24 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 13:10:34 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote:
> At least he is trying. There's no need for bashing people who try to
> implement new ideas.
I'm not. I'd rather he listened to new ideas and took feedback but that
is his business and the community has ways of dealing with that problem
that work (see GGI, or Eric Raymonds new kernel config tool)
I do however object when he tries to use a research project as an
execuse for slowing down a much needed merge of the current DRI code
into Xorg.
Thats an unrelated issue to the mesa solo work.
Alan
From jonsmirl at yahoo.com Sun Jun 13 14:03:54 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 14:03:58 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Alan Cox <[email protected]> wrote:
> Secondly every line of code you put in the kernel has to be audited,
> analysed and can introduce security holes or crash the machine. Its
> harder to debug and its harder to write in the first place. There are
> very good reasons (see the original DRI paper) for putting as much as
> you can in user space. The Mesa X work also tries to keep as much as
> possible in user space - including designs for mode computation by
> kernel->user callback.
There is a fine line to walk with the user space versus kernel split. For
example the X server should not be changing the PCI bus routing from user space
like it currently does. It should also not be capable of moving things like the
framebuffer address around in PCI space. The kernel provides an API for doing
those things and X should be using it. You just can't move hardware around
without telling the kernel and then expect hotplug to work. If things aren't
where the kernel expects them to be the kernel may assign the hotplug device
addresses on top of them.
On the other hand you shouldn't put too much into the kernel. Mode setting is an
example of this. It takes a lot of code to read a monitor's DDC and then compute
the mode. This code can easily run in user space and then use an IOCTL to set
the final result into the hardware. fbdev is trying to do all of this in kernel
space.
Finally there is the issue of needing root priv. With a properly designed kernel
driver the X server does not need to map the hardware into user space and run as
root. DRM + mode + cursor equals a driver capable of support a non-root X server
.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From jonsmirl at yahoo.com Sun Jun 13 14:11:51 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 14:11:53 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Alan Cox <[email protected]> wrote:
> On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote:
> > At least he is trying. There's no need for bashing people who try to
> > implement new ideas.
>
> I'm not. I'd rather he listened to new ideas and took feedback but that
> is his business and the community has ways of dealing with that problem
> that work (see GGI, or Eric Raymonds new kernel config tool)
I'm listening. What is your proposal for getting Linux into a position where it
can fully utilize 3D hardware acceleration engines?
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From jonsmirl at yahoo.com Sun Jun 13 14:29:02 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 14:29:04 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Matt Sealey <[email protected]> wrote:
> We need a low-level "kernel" graphics API (much like Windows
> has, although Windows favours microkernels with high-level
> kernel functionality, rather than monolithic kernels with
> user-level functionality.. the two philosophies are at odds)
> which can perform and accelerate the expected functionality of
> everything from router to PDA, past desktop to display of
> remote-served apps.
I'm not proposing a new kernel graphics API. Instead I am proposing that the
primary user space graphics API be OpenGL. This make no comment on what the
kernel API would look like. In fact I would expect that there will be many
variations on the kernel API. The proposal is simply that the OpenGL API becomes
the primary user space API for programming the graphics hardware.
This does not mean that X is dead. xserver is in the middle of implementing xlib
and render on top of the OpenGL drawing API. OpenGL would be used to replace XAA
in the current XFree system. All existing X apps won't notice the change except
that drawing gets faster.
Some points in favor of OpenGL as the primary user-space graphics API
1) accelerated graphics hardware is designed to accelerate OpenGL
2) it is standardized and controlled by the ARB, OpenGL is well designed.
3) free implementations exist
4) it is taught in schools
5) books on it are widely available
6) It is higher level than XAA. This provides more room for hardware integration
over time. For example filters.
7) It can run on 2D hardware - software mesa
8) It can be made tiny - OpenGL-ES is 100K and it is shipping in cell phones
9) Key vendors - ATI/Nvidia already own OpenGL drivers
Try making a list like this for other solutions like directfb or kgi and see how
they compare.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From jonsmirl at yahoo.com Sun Jun 13 14:41:31 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 14:41:34 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- John Dennis <[email protected]> wrote:
> > With a properly designed kernel driver the X server does not need
> > to map the hardware into user space and run as root.
>
> How do you efficiently control the hardware then without incuring the overhead
> of user/system transition on ioctl's? How many iotcl's and at what granularity
> are you suggesting?
>
> Are you assuming a device which can read and execute register settings from a
> memory buffer, e.g. the dma ring buffer style devices?
Of course the dma ring buffer devices are the best and decent, modern cards
implement it that way.
On modern processors the user/system transition is minor compared to the time
needed for a bitblt over the PCI bus. Doing everthing in user space was
important on a 286, but is it still a significant performance gain vs the
security issues of running X as root? You can always batch the drawing
operations to reduce the ring transition overhead. If performance is that
critical spend $35 for a DMA based card.
These arguments are different for an embedded device where everything runs as
root. Go ahead and program everything from user space to get the performance
gain. Worms and trojans aren't as big of problem for embedded devices.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From michel at daenzer.net Sun Jun 13 15:05:46 2004
From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=)
Date: Sun Jun 13 15:05:58 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1087164346.4193.206.camel@localhost>
On Sun, 2004-06-13 at 12:35 -0700, Jon Smirl wrote:
>
> 2) copy of the user space code from XFree86 into a standalone library - now yo
u
> have to be root to play with the chip.
> 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the
> work as possible in user space and just pass final register values to the
> IOCTLs.
>
> I would like to see #3. I have implemented #3 locally for the radeon but there
> is no acceptance for adding it to main DRM drivers.
Of course, you neglect to mention the reasons for that. For one, you
haven't presented an interface yet that you have shown to remove the
need to be root and a significant amount of code from the kernel at the
same time. Obviously, immature solutions can't go into the DRM trunk and
consequently the kernel because if they don't work out, they can become
maintenance nightmares. You have repeatedly been encouraged to develop a
prototype system on branches or separate trees though. Don't wait for
everyone else to drop everything else.
--
Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From alan at lxorguk.ukuu.org.uk Sun Jun 13 14:08:23 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 15:11:32 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 22:41, Jon Smirl wrote:
> On modern processors the user/system transition is minor compared to the time
> needed for a bitblt over the PCI bus.
As a percentage of system time the user/system transition cost has been
rising not falling on x86 processors. Its especially bad when you want
large memory support on 32bit x86 (x86-64 isnt so bad here)
[If you want to verify my claim just try Larry McVoy's lmbench latency
tests on different setups]
Really however it isnt an important debate. The DDX and XAA driver
interface means the driver module is responsible for
- Obtain access to resources
- Drive resources directly or indirectly
- Arbitrate resources with OS according to OS policy
So you can write an XOrg driver that does everything kernel side if you
wish. For some DMA cards such as the radeon the existing code already
does sometimes use kernel side support for DMA rings when DRI modules
are present.
The core X server really doesn't care what "obtain access to resources"
and "drive resources" come down to. The Linux fb driver uses the kernel
for resources, the Glide driver uses an external drawing library and
many other drivers bang on the hardware.
As you move up the layers you can take more control of the rendering
decisions too. XAA figures out how to use the existing 2D drawing
subsystems and not much else. You can hook above XAA to achieve other
things. Thus it may ultimately be a mistake to see Xorg and Keith's work
ultimately as seperate things. I see no reason an Xorg server cannot
exist that uses Mesa as its base drawing library on one screen and XAA
on another.
> These arguments are different for an embedded device where everything runs as
> root. Go ahead and program everything from user space to get the performance
> gain. Worms and trojans aren't as big of problem for embedded devices.
Tell that to the Japanese mobile phone manufacturers.
PS: and before telling me to get a $35 new card, please tell me where it
fits in my PA-RISC box, on my iPaq, in my old thinkpad laptop, and so
on. Xorg is a bit bigger than PCdom.
Alan
From alan at lxorguk.ukuu.org.uk Sun Jun 13 14:12:17 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sun Jun 13 15:15:26 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sul, 2004-06-13 at 22:58, Mike Mestnik wrote:
> The DRM is a kernel driver that allowes the user-apps to use a 3D cards
> API. Fbdev is smaller then the DRM and will be asimulated and it's
> functions emulated or replaced.
On Linux and FreeBSD only, and there isnt yet a consensus on the
Fbdev+DRI+text console+security+hotplug pile other than that it needs to
be resolved.
Hopefully the kernel summit in July will provide some more definitive
answers on plans and once Linus has agreed to something (or destroyed
all the ideas one by one 8)) it becomes easier to plan.
In the shorter term however the sooner the current DRI is in the current
X server the better. The kernel expects recent DRI, many users require
it (eg for all modern laptops) with Linux and FreeBSD.
Alan
From keithp at keithp.com Sun Jun 13 17:22:15 2004
From: keithp at keithp.com (Keith Packard)
Date: Sun Jun 13 17:23:03 2004
Subject: [Xorg] DRI merging
In-Reply-To: Your message of "Sat, 12 Jun 2004 10:47:07 PDT."
<1087062427.81204.72.camel@leguin>
Message-ID: <[email protected]>
Around 10 o'clock on Jun 12, Eric Anholt wrote:
> I am definitely in favor of the DRI X tree stuff being a branch on the
> X.Org tree.
"me too".
A question is how the future modularization of the system would impact this
process. I'm hoping the answers will be "mostly positive", but discussion
is welcome.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040613/de5a02ad/attach
ment.pgp
From keithp at keithp.com Sun Jun 13 17:39:12 2004
From: keithp at keithp.com (Keith Packard)
Date: Sun Jun 13 17:39:58 2004
Subject: [Xorg] DRI merging
In-Reply-To: Your message of "Sun, 13 Jun 2004 20:04:10 BST."
<[email protected]>
Message-ID: <[email protected]>
Around 20 o'clock on Jun 13, Alan Cox wrote:
> Secondly every line of code you put in the kernel has to be audited,
> analysed and can introduce security holes or crash the machine.
The same is (alas) all too true for code within the X server as well. An
ideal situation would have the X server running unprivledged on top of a
kernel driver that validated commands to the graphics card. That's one of
the motivations to moving to a DRI-like environment for the X server.
Using the OpenGL API provides that in a more "vendor neutral" way than
going directly to DRI.
However, even for plain 2D only X servers, I would advocate a similar
driver architecture, albiet with a significantly simpler kernel module.
Do everything possible in user mode, but no more.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040613/c74cb274/attach
ment.pgp
From daniel at freedesktop.org Sun Jun 13 20:57:47 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 13 20:57:47 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 13, 2004 at 12:13:43PM -0700, Jon Smirl wrote:
> So if my ideas are so bad, why don't you propose your own solution to the
> Longhorn problem? I have no attachment to anything I've proposed, I'll work on
> any solution that solves the main problem.
Project Utopia, fixing window managers to do things like use XSync()
whereever possible, migrate toolkits to use XCB and hand-optimise for
common paths, et al.
I think that's going to buy you a lot more than X on top of GL, for a
lot less work. Because you know why? X on GL still requires
not-insignificant work on the desktop to make it workable and coherent.
More than what I've proposed, I dare say.
--
Daniel Stone <[email protected]>
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/20040614/f8588522/attach
ment.pgp
From jonsmirl at yahoo.com Sun Jun 13 22:07:59 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 22:08:01 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X on GL has no impact on remote X. Tests with glitz show a 100:1 speed
improvement for local drawing.
--- Daniel Stone <[email protected]> wrote:
> On Sun, Jun 13, 2004 at 12:13:43PM -0700, Jon Smirl wrote:
> > So if my ideas are so bad, why don't you propose your own solution to the
> > Longhorn problem? I have no attachment to anything I've proposed, I'll work
> on
> > any solution that solves the main problem.
>
> Project Utopia, fixing window managers to do things like use XSync()
> whereever possible, migrate toolkits to use XCB and hand-optimise for
> common paths, et al.
>
> I think that's going to buy you a lot more than X on top of GL, for a
> lot less work. Because you know why? X on GL still requires
> not-insignificant work on the desktop to make it workable and coherent.
> More than what I've proposed, I dare say.
>
> --
> Daniel Stone
> <[email protected]>
> freedesktop.org: powering your desktop
> http://www.freedesktop.org
>
> ATTACHMENT part 2 application/pgp-signature name=signature.asc
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From daniel at freedesktop.org Sun Jun 13 22:20:38 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 13 22:20:37 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 13, 2004 at 10:07:59PM -0700, Jon Smirl wrote:
> X on GL has no impact on remote X. Tests with glitz show a 100:1 speed
> improvement for local drawing.
... on 3D-heavy cards, no?
I wonder what those same tests would show for the S3 Trio64 my sister
runs, or the ATI RageIIC my mother runs. I'm not disparaging your
efforts, but:
* A first-class windowing system is wasted if all the apps around are
crap, or don't make use of it, or both.
* Have you tested on lower-end cards, or only the new, insane,
3D-centric cards? A performance hit on already-slow graphics
hardware would be bad.
--
Daniel Stone <[email protected]>
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/20040614/e56d5de7/attach
ment.pgp
From jonsmirl at yahoo.com Sun Jun 13 22:42:58 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 22:43:01 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X on GL won't ship anywhere for at least a year. It will probably be two years
before it is in wide spread use. You can get good 3D cards for $35 now, in two
years due to Longhorn all systems will be shipping with them.
I still own an 8086 based machine with no protected mode, does that mean that
Linux should not support protect mode? You can;t look backwards at hardware
support, if you do you will never add any new features.
There are plans for supporting non-accelerated cards, but you can't expect them
to perform like a decent 3D one. No amount of software is going to make my 8086
play a reasonable game of Quake.
--- Daniel Stone <[email protected]> wrote:
> On Sun, Jun 13, 2004 at 10:07:59PM -0700, Jon Smirl wrote:
> > X on GL has no impact on remote X. Tests with glitz show a 100:1 speed
> > improvement for local drawing.
>
> ... on 3D-heavy cards, no?
>
> I wonder what those same tests would show for the S3 Trio64 my sister
> runs, or the ATI RageIIC my mother runs. I'm not disparaging your
> efforts, but:
> * A first-class windowing system is wasted if all the apps around are
> crap, or don't make use of it, or both.
> * Have you tested on lower-end cards, or only the new, insane,
> 3D-centric cards? A performance hit on already-slow graphics
> hardware would be bad.
>
> --
> Daniel Stone
> <[email protected]>
> freedesktop.org: powering your desktop
> http://www.freedesktop.org
>
> ATTACHMENT part 2 application/pgp-signature name=signature.asc
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From daniel at freedesktop.org Sun Jun 13 22:51:44 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 13 22:51:45 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 13, 2004 at 10:42:58PM -0700, Jon Smirl wrote:
> X on GL won't ship anywhere for at least a year. It will probably be two years
> before it is in wide spread use. You can get good 3D cards for $35 now, in two
> years due to Longhorn all systems will be shipping with them.
So? My sister still uses a P120, and is happy with it. Why should she be
forced to upgrade?
> I still own an 8086 based machine with no protected mode, does that mean that
> Linux should not support protect mode? You can;t look backwards at hardware
> support, if you do you will never add any new features.
I am not suggesting *removing* support, rather *adding* support. Should
we get rid of support for sub-AthlonXP-class while we're at it? No-one
uses those old pieces of crap.
> There are plans for supporting non-accelerated cards, but you can't expect the
m
> to perform like a decent 3D one. No amount of software is going to make my 808
6
> play a reasonable game of Quake.
Yeah, but windowing systems shouldn't have the same system requirements
as Quake.
--
Daniel Stone <[email protected]>
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/20040614/fe3ab92b/attach
ment.pgp
From jonsmirl at yahoo.com Sun Jun 13 23:44:06 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Sun Jun 13 23:44:11 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Daniel Stone <[email protected]> wrote:
> On Sun, Jun 13, 2004 at 10:42:58PM -0700, Jon Smirl wrote:
> > X on GL won't ship anywhere for at least a year. It will probably be two
> years
> > before it is in wide spread use. You can get good 3D cards for $35 now, in
> two
> > years due to Longhorn all systems will be shipping with them.
>
> So? My sister still uses a P120, and is happy with it. Why should she be
> forced to upgrade?
No one is going to force anyone to upgrade. Just continue using the software
that you have installed right now. I've watched several people install Windows
XP over Win95 and then complain about how slow their machine became.
>
> > I still own an 8086 based machine with no protected mode, does that mean
> that
> > Linux should not support protect mode? You can;t look backwards at hardware
> > support, if you do you will never add any new features.
>
> I am not suggesting *removing* support, rather *adding* support. Should
> we get rid of support for sub-AthlonXP-class while we're at it? No-one
> uses those old pieces of crap.
>
> > There are plans for supporting non-accelerated cards, but you can't expect
> them
> > to perform like a decent 3D one. No amount of software is going to make my
> 8086
> > play a reasonable game of Quake.
>
> Yeah, but windowing systems shouldn't have the same system requirements
> as Quake.
>
> --
> Daniel Stone
> <[email protected]>
> freedesktop.org: powering your desktop
> http://www.freedesktop.org
>
> ATTACHMENT part 2 application/pgp-signature name=signature.asc
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From daniel at freedesktop.org Sun Jun 13 23:51:21 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 13 23:51:21 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 13, 2004 at 11:44:06PM -0700, Jon Smirl wrote:
> --- Daniel Stone <[email protected]> wrote:
> > On Sun, Jun 13, 2004 at 10:42:58PM -0700, Jon Smirl wrote:
> > > X on GL won't ship anywhere for at least a year. It will probably be two
> > years
> > > before it is in wide spread use. You can get good 3D cards for $35 now, in
> > two
> > > years due to Longhorn all systems will be shipping with them.
> >
> > So? My sister still uses a P120, and is happy with it. Why should she be
> > forced to upgrade?
>
> No one is going to force anyone to upgrade. Just continue using the software
> that you have installed right now. I've watched several people install Windows
> XP over Win95 and then complain about how slow their machine became.
Right; she still uses Win98.
As a distributor as well as an upstream hacker, this prospect makes me
deeply unhappy.
--
Daniel Stone <[email protected]>
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/20040614/71a1d5a2/attach
ment.pgp
From daniel at freedesktop.org Mon Jun 14 00:19:52 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 14 00:19:53 2004
Subject: [Xorg] DRI merging
In-Reply-To: <Pine.LNX.4.58.0406140751140.14086@skynet>
References: <[email protected]>
<Pine.LNX.4.58.0406140751140.14086@skynet>
Message-ID: <[email protected]>
On Mon, Jun 14, 2004 at 08:00:59AM +0100, Dave Airlie wrote:
> > > So? My sister still uses a P120, and is happy with it. Why should she be
> > > forced to upgrade?
>
> I think that is a bit petty really, please try and keep this
> discussion some way in the bounds of logic, at some point you have to
> throw away older systems, X works on these systems now, we want to build a
> new version of X that works on top of newer cards using features of these
> cards, the older systems can still use X as they do now however
> development will slow on XAA drivers and newer applications will use newer
> features stopping them from working on the older systems...
>
> Just because we develop a new graphics sub-system, it doesn't mean you
> have to run it, I belive there is space (if we merge fbdev functionality
> into the drm) to build an XAA Xserver on top of it using the drm to do the
> mode setting card resetting, pci access and any locking, it just won't run
> 3D apps, it can still run X/GNOME etc..
I just do not see the world that Jon envisions, in which old hardware
has simply vanished. I know it hasn't, because there are many machines
around me - and my friends, and family, and everyone I know - which are
simply incapable of running it.
Just because 'the competition'[0] is locking older hardware out, doesn't
mean we should, too. I'm all for this new infrastructure which allows us
to harness the full power of cards which still cost a reasonable amount
in $au (I still own a rv250), but surely there must be some sort of
fallback for those of us who are still to get with the program, realise
that hardware is cheap, and throw a month's rent at a new computer[1].
:) d, stuck in the technology stone-age[2]
[0]: While we're at it, 'us' vs. 'them/you' is petty and unconstructive.
[1]: You'd be lucky to include a r3xx in a $au800-$au1k machine.
[2]: Communicating with you by the graces of a 56k modem.
--
Daniel Stone <[email protected]>
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/20040614/ad44f66c/attach
ment.pgp
From eich at pdx.freedesktop.org Mon Jun 14 02:44:07 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Jun 14 02:45:17 2004
Subject: [Xorg] New committer process?
In-Reply-To: [email protected] wrote on Friday, 11 June 2004 at 23:15:22 -0700
References: <1087020922.86211.49.camel@leguin>
Message-ID: <[email protected]>
Eric Anholt writes:
> What is the process for bringing new committers in, or do we have one
> yet? Would it be OK for existing committers to sponsor new ones, or
> should there be some sort of approval?
>
I've written up a draft on:
http://freedesktop.org/bin/view/XOrg/CvsPage#CVS_write_access
and
http://freedesktop.org/XOrg/CvsPolicy
I've tried to take into account discussions we had previously on
this and other lists.
Please note that this is only a draft and should serve as an RFC.
I'm not aware of any comments so far.
Egbert.
From keith at tungstengraphics.com Mon Jun 14 03:01:59 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Mon Jun 14 03:02:23 2004
Subject: DRI CVS tree futures, was Re: [Xorg] DRI merging
In-Reply-To: <1087062427.81204.72.camel@leguin>
References: <1087021032.86211.53.camel@leguin> <1087051483.4193.169.camel@local
host>
<1087062427.81204.72.camel@leguin>
Message-ID: <[email protected]>
Eric Anholt wrote:
> I am definitely in favor of the DRI X tree stuff being a branch on the
> X.Org tree.
I'd prefer to look at it slightly differently:
1) I'd like to get the current work in the DRI tree to a stable state, meaning:
a) finish (or part finish) Ian's NEW_INTERFACE work
b) import a stable version of mesa and the drivers into xc/extras, break
ing
the need to track current mesa.
2) I'd like to see that stabilized Mesa and updated libGL work exported to
X.org and XFree86.
3) At this point, the DRI tree will contain nothing not in either X.org or
XFree86. Now, people can choose what they would like to do:
a) Continue using the DRI tree and all the merge hassles it has involved
,
potentially with the extra bonus of 2 divergent trees to try and merge with.
b) Delete/disable the DRI tree. People who want to work on libGL.so, th
e 2D
DDX or indirect rendering can switch over to X.org where presumably everyone
who has demonstrated interest & aptitude will be able to secure CVS access.
or c) Delete/disable the DRI tree and try and do development by submitti
ng
patches to XFree86.
After splitting off the drivers to Mesa and DRM to it's own project, I don't
see why the remaining X development work (DDX changes, libGL.so evolution,
indirect rendering changes, etc) can't just take place in the normal
development stream of X.org (or XFree86 for that matter) -- IE. I don't see
why there even needs to be a branch for DRI work as opposed to other X, DDX or
library work -- the distinction seems artificial.
Of course, it's not for me to say how X.org (or XFree86) should be developed,
but it does seem like the X development to be done by developers formerly
known as DRI doesn't differ in any huge respect from the X development done by
others.
If some particular project were particularly ambitious in its scope, then yes,
a branch might be in order, but I don't think that saying "oh, this is DRI
stuff, it should go on a different branch to regular X development" makes a
lot of sense.
Keith
From daniel at freedesktop.org Mon Jun 14 03:06:22 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 14 03:06:22 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <1087020922.86211.49.camel@leguin>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 14, 2004 at 11:44:07AM +0200, Egbert Eich wrote:
> Eric Anholt writes:
> > What is the process for bringing new committers in, or do we have one
> > yet? Would it be OK for existing committers to sponsor new ones, or
> > should there be some sort of approval?
> >
>
> I've written up a draft on:
>
> http://freedesktop.org/bin/view/XOrg/CvsPage#CVS_write_access
>
> and
>
> http://freedesktop.org/XOrg/CvsPolicy
>
> I've tried to take into account discussions we had previously on
> this and other lists.
> Please note that this is only a draft and should serve as an RFC.
> I'm not aware of any comments so far.
I can't seem to edit any wiki pages right now, so you need to
s/site-wranglers/sitewranglers/ on the first page.
:) d
--
Daniel Stone <[email protected]>
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/20040614/e6b47b21/attach
ment.pgp
From grifis87 at virgilio.it Mon Jun 14 04:41:26 2004
From: grifis87 at virgilio.it (Giovanni)
Date: Mon Jun 14 03:17:08 2004
Subject: [Xorg] debrix in xserver-commit
Message-ID: <[email protected]>
I know it's a stupid question, but I didn't find anything about it...what's
debrix?
What's his connection with xorg xserver?
Is it the new modularizated version of xorg that will go to trunk soon or
later?
Does it work?
Thank you very much :)
From rafael.espindola at ic.unicamp.br Mon Jun 14 04:19:50 2004
From: rafael.espindola at ic.unicamp.br (Rafael =?iso-8859-1?q?=C1vila_de_Esp=ED
ndola?=)
Date: Mon Jun 14 04:17:35 2004
Subject: [Xorg] Adding support for A4Tech KB-21 keyboard multimedia keys
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Em Sunday 13 June 2004 10:57, ismail donmez escreveu:
> Hi all,
>
> I created 3 small patches adding support for A4Tech KB-21 keyboard's
> multimedia keys. Please check
> http://freedesktop.org/bugzilla/show_bug.cgi?id=744 for details.
Could you please forward these to XKeyboardConfig ([email protected])
Thanks
> Cheers,
> /ismail d?nmez
Rafael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAzYnaLlrfGJ8JUHwRAqNJAKDdVztCOlm2lOoX+GLR6UaTLhAFXgCZAccw
286kUmxC9hOoqc/5P1T+vjc=
=VJ9z
-----END PGP SIGNATURE-----
From keithp at keithp.com Mon Jun 14 09:37:09 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 14 09:37:26 2004
Subject: [Xorg] New committer process?
In-Reply-To: Your message of "Mon, 14 Jun 2004 11:44:07 +0200."
<[email protected]>
Message-ID: <[email protected]>
Around 11 o'clock on Jun 14, Egbert Eich wrote:
> I've tried to take into account discussions we had previously on this and
> other lists. Please note that this is only a draft and should serve as an
> RFC. I'm not aware of any comments so far.
Let's have a few comments then.
Given that CVS is completely insecure (anyone with write access can damage
or destroy the repository), I suggest that we need some minimal process for
granting write access.
I don't know what form this should take though; the proposal for
'sponsorship' has a lot of benefits, but does tend to shut out people who
are new on the scene. We might also consider granting access in some kind
of incremental fashion; with early access limited to 'less sensitive'
parts of the tree. It would also be nice to have some kind of
identification for each committer to prevent spoofed access.
Process sucks.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040614/07620cbc/attach
ment.pgp
From keithp at keithp.com Mon Jun 14 09:25:10 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 14 09:48:55 2004
Subject: [Xorg] DRI merging
In-Reply-To: Your message of "Mon, 14 Jun 2004 10:13:46 BST."
<[email protected]>
Message-ID: <[email protected]>
Around 10 o'clock on Jun 14, "Matt Sealey" wrote:
> I half-baked agree with you! I am just looking for an accelerated
> 2D API that isn't permanently in testing and isn't X.
I'd like to think that cairo fits in this space; it's not X specific and
has acceleratable back-ends for GL and X.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040614/e0774bcf/attach
ment.pgp
From p.postmus at st.hanze.nl Mon Jun 14 11:32:55 2004
From: p.postmus at st.hanze.nl (Peter Postmus)
Date: Mon Jun 14 11:33:28 2004
Subject: [Xorg] DRI merging
Message-ID: <[email protected]>
I've been reading this thread, and the arguments in it. Although I do
write small programs, I consider myself to be more of a Linux user than a
developer, which may mean this isn't the place for me to comment on this
discussion, but I think you might be missing one thing.
Although Windows Longhorn will have this all-new graphical system called
"Aero", it doesn't have to be turned on. In fact - if I'm not mistaken - the
Longhorn GUI will contain three layers: Aero Glass, Aero and a "Classic mode"
layer. If your graphics hardware can't handle Aero Glass or Aero, it's
possible to turn off these layers in Longhorn, and have about the same GUI as
is present in Windows 2000.
Please note, I'm no expert in this field and I don't know if such an approach
would even be possible on the X.org or xserver X servers (that name
definitely needs to be changed ;)), without changing the design too much. But
I do agree with John Smirl that, if Linux won't have a comparable GUI to
Windows Longhorn by the time it's released, many users that have converted
from Windows to Linux in the past, will convert to Longhorn again. I also
think compatibility with other UNIX-like OS's should be preserved, but it
sounds like this Longhorn-style approach could make that possible as well.
--
Met vriendelijke groeten,
With kind regards,
Peter Postmus
WWW: http://starbase218.ath.cx
From keithp at keithp.com Mon Jun 14 11:37:01 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 14 11:37:31 2004
Subject: [Xorg] New committer process?
In-Reply-To: Your message of "Mon, 14 Jun 2004 19:53:26 +0300."
<[email protected]>
Message-ID: <[email protected]>
Around 19 o'clock on Jun 14, Ely Levy wrote:
> Isn't SSH safe enough?
> commiting with SSH sounds preety good way to prevent spoofing IMHO
My question was higher level -- how do we authenticate people we give
accounts to on the machine in the first place. Right now, we're mostly
letting each project vette people with informal irc or email
"authentication"; that works pretty well when you know the people involved,
otherwise it doesn't work.
Once people have accounts on the machine, SSH had better provide a
reasonable level of security. I'd certainly be a lot happier with a
more secure repository though (yes, CVS sucks, but no, we're not switching
right now).
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040614/987941cd/attach
ment-0001.pgp
From daniel at freedesktop.org Mon Jun 14 11:40:32 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 14 11:40:31 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 14, 2004 at 08:32:55PM +0200, Peter Postmus wrote:
> Please note, I'm no expert in this field and I don't know if such an approach
> would even be possible on the X.org or xserver X servers (that name
> definitely needs to be changed ;)),
It certainly needs a change. If you want to refer to what's commonly
known as 'the fd.o xserver', please use KDrive: that's the name of the
DDX that most people use under xserver.
> without changing the design too much. But
> I do agree with John Smirl that, if Linux won't have a comparable GUI to
> Windows Longhorn by the time it's released, many users that have converted
> from Windows to Linux in the past, will convert to Longhorn again. I also
> think compatibility with other UNIX-like OS's should be preserved, but it
> sounds like this Longhorn-style approach could make that possible as well.
Sure, that's a good idea; one of my main points in all this is that a
GL-based X server is not an anathema to Linux's desktop problems. More
work is needed on the desktop front (D-BUS, HAL, Project Utopia, et al)
before Linux can become a competitor on the next-generation desktop
front: it's not all about the windowing system.
Which isn't to say that this work shouldn't be done. But this point, and
the fact that old hardware is incredibly abundant, needs to be kept in
mind as well.
--
Daniel Stone <[email protected]>
freedesktop.org: powering your desktop http://www.freedesktop.org
From mcnichol at austin.ibm.com Mon Jun 14 12:32:03 2004
From: mcnichol at austin.ibm.com ([email protected])
Date: Mon Jun 14 12:32:38 2004
Subject: [Xorg] VFB in fd.o xserver.
Message-ID: <[email protected]>
I'm trying to keep track of some of the accessibility issues,
and was hoping to find some info about the Virtual Frame Buffer.
Is there a working implementation of vfb in the fd.o xserver?
Thanks
Dan
From reed at reedmedia.net Mon Jun 14 12:48:45 2004
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon Jun 14 12:49:09 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On Mon, 14 Jun 2004, Peter Postmus wrote:
> I do agree with John Smirl that, if Linux won't have a comparable GUI to
> Windows Longhorn by the time it's released, many users that have converted
> from Windows to Linux in the past, will convert to Longhorn again. I also
I am a non-Windows user. What is so great about this "Longhorn" that would
convince someone to switch to it?
I already read the posting indicating significant X performance
improvement. So Longhorn will have a quicker display? For my needs, my old
video cards running X seem good enough.
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
From reed at reedmedia.net Mon Jun 14 12:53:07 2004
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon Jun 14 12:53:15 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On Mon, 14 Jun 2004, Keith Packard wrote:
> > Isn't SSH safe enough?
> > commiting with SSH sounds preety good way to prevent spoofing IMHO
>
> My question was higher level -- how do we authenticate people we give
> accounts to on the machine in the first place. Right now, we're mostly
> letting each project vette people with informal irc or email
> "authentication"; that works pretty well when you know the people involved,
> otherwise it doesn't work.
One of the groups I am a member of requires GPG/PGP keys signed by another
member already part of the project.
And they have to meet in person (I was told) for the verification.
Also, we require sponsors.
Jeremy C. Reed
BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/
From Stuart.Kreitman at Sun.COM Mon Jun 14 13:04:20 2004
From: Stuart.Kreitman at Sun.COM (Stuart Kreitman)
Date: Mon Jun 14 13:03:40 2004
Subject: [Xorg] VFB in fd.o xserver.
References: <[email protected]>
Message-ID: <[email protected]>
There is "dummy_drv.o" which provides the needed function.
skk
[email protected] wrote:
>I'm trying to keep track of some of the accessibility issues,
>and was hoping to find some info about the Virtual Frame Buffer.
>
>Is there a working implementation of vfb in the fd.o xserver?
>
>Thanks
>Dan
>
>_______________________________________________
>xorg mailing list
>[email protected]
>http://freedesktop.org/mailman/listinfo/xorg
>
>
From fcatrin at tuxpan.com Mon Jun 14 13:03:30 2004
From: fcatrin at tuxpan.com (Franco Catrin L.)
Date: Mon Jun 14 13:03:52 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
El lun, 14-06-2004 a las 15:48, Jeremy C. Reed escribi?:
> On Mon, 14 Jun 2004, Peter Postmus wrote:
>
> > I do agree with John Smirl that, if Linux won't have a comparable GUI to
> > Windows Longhorn by the time it's released, many users that have converted
> > from Windows to Linux in the past, will convert to Longhorn again. I also
>
> I am a non-Windows user. What is so great about this "Longhorn" that would
> convince someone to switch to it?
>
> I already read the posting indicating significant X performance
> improvement. So Longhorn will have a quicker display? For my needs, my old
> video cards running X seem good enough.
Longhorn will have a different display architecture than current Windows
machines. Some sort of MacOSX type of display architecture, but with
display state "on the server".
Check this out:
http://www.eightypercent.net/Archive/2004/05/18.html#a185
--
Franco Catrin L. TUXPAN
http://www.tuxpan.com/fcatrin
From keithp at keithp.com Mon Jun 14 13:18:46 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 14 13:19:08 2004
Subject: [Xorg] VFB in fd.o xserver.
In-Reply-To: Your message of "Mon, 14 Jun 2004 14:32:03 CDT."
<[email protected]>
Message-ID: <[email protected]>
Around 14 o'clock on Jun 14, [email protected] wrote:
> Is there a working implementation of vfb in the fd.o xserver?
Seen Xfake? That's a kdrive-based X server with a malloc'ed frame buffer.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040614/dba49e7b/attach
ment.pgp
From alexdeucher at gmail.com Mon Jun 14 13:44:36 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Mon Jun 14 13:44:52 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, 14 Jun 2004 20:32:55 +0200, Peter Postmus <[email protected]> wrote:
>
> I've been reading this thread, and the arguments in it. Although I do
> write small programs, I consider myself to be more of a Linux user than a
> developer, which may mean this isn't the place for me to comment on this
> discussion, but I think you might be missing one thing.
>
> Although Windows Longhorn will have this all-new graphical system called
> "Aero", it doesn't have to be turned on. In fact - if I'm not mistaken - the
> Longhorn GUI will contain three layers: Aero Glass, Aero and a "Classic mode"
> layer. If your graphics hardware can't handle Aero Glass or Aero, it's
> possible to turn off these layers in Longhorn, and have about the same GUI as
> is present in Windows 2000.
Keep in mind that longhorn is also delayed and probably won't show up
for another year or two. about the same time it would take us to
develop the "new" X server.
Alex
From alan at lxorguk.ukuu.org.uk Mon Jun 14 12:48:14 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Mon Jun 14 13:51:22 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Llu, 2004-06-14 at 17:37, Keith Packard wrote:
> Given that CVS is completely insecure (anyone with write access can damage
> or destroy the repository), I suggest that we need some minimal process for
> granting write access.
Or booby trap the repository.
CVS acls can help a lot here - you can limit people to drivers they are
supposed to be hacking on (which also helps avoid accidents). I'd be
happier with ACLs, if only because I'll know I can't actually trash
someone elses work.
Alan
From nomercy at eutonian.com Mon Jun 14 13:58:42 2004
From: nomercy at eutonian.com (Brandon Mercer)
Date: Mon Jun 14 13:57:36 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alan Cox wrote:
>On Llu, 2004-06-14 at 17:37, Keith Packard wrote:
>
>
>>Given that CVS is completely insecure (anyone with write access can damage
>>
>>
How come you guys weren't this talkative when I posted a question? I
didn't even get so much as a flame from the group to tell me my message
was stupid.
Brandon
From mcnichol at austin.ibm.com Mon Jun 14 14:11:31 2004
From: mcnichol at austin.ibm.com ([email protected])
Date: Mon Jun 14 14:12:06 2004
Subject: [Xorg] VFB in fd.o xserver.
Message-ID: <[email protected]>
Thanks Keith.
Any idea which branch that might be in?
I don't see it in the head branch.
Dan
> From [email protected] Mon Jun 14 15:19:14 2004
>
>
> Around 14 o'clock on Jun 14, [email protected] wrote:
>
> > Is there a working implementation of vfb in the fd.o xserver?
>
> Seen Xfake? That's a kdrive-based X server with a malloc'ed frame buffer.
>
> -keith
>
>
>
From reed at reedmedia.net Mon Jun 14 14:19:50 2004
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon Jun 14 14:19:59 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On Mon, 14 Jun 2004, Brandon Mercer wrote:
> How come you guys weren't this talkative when I posted a question? I
> didn't even get so much as a flame from the group to tell me my message
> was stupid.
I guess you are referring to the "Dual Heads with ati 7200" posting. Maybe
because nobody on this list uses dual heads and/or ATI 7200 or they didn't
have time to volunteer to help with it.
Maybe it is a big and listed in bugzilla already. Or maybe it is a bug and
you should submit it.
It is interesting that your email's logs said to "Please consult the The
X.Org Foundation support at http://wiki.X.Org for help." But that webpage
doesn't seem like any support webpage.
Good luck,
Jeremy C. Reed
technical support & remote administration
http://www.pugetsoundtechnology.com/
From jonsmirl at yahoo.com Mon Jun 14 14:56:58 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Mon Jun 14 14:57:00 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Alex Deucher <[email protected]> wrote:
> Keep in mind that longhorn is also delayed and probably won't show up
> for another year or two. about the same time it would take us to
> develop the "new" X server.
With two people working on mesa-solo and xserver it's going to take more than
two years to finish it. Linux could get a major PR win here if we pulled
together to build the new system in less time. It is much more valuable for
Linux PR to be seen as leading the new technology rather than copying was MS has
done.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
From nomercy at eutonian.com Mon Jun 14 15:00:38 2004
From: nomercy at eutonian.com (Brandon Mercer)
Date: Mon Jun 14 14:59:03 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Jeremy C. Reed wrote:
>On Mon, 14 Jun 2004, Brandon Mercer wrote:
>
>
>
>>How come you guys weren't this talkative when I posted a question? I
>>didn't even get so much as a flame from the group to tell me my message
>>was stupid.
>>
>>
>
>I guess you are referring to the "Dual Heads with ati 7200" posting. Maybe
>because nobody on this list uses dual heads and/or ATI 7200 or they didn't
>have time to volunteer to help with it.
>
>
Yes, you're right this is the posting I had. Even still, someone should
have said SOMETHING about it.
>Maybe it is a big and listed in bugzilla already. Or maybe it is a bug and
>you should submit it.
>
>It is interesting that your email's logs said to "Please consult the The
>X.Org Foundation support at http://wiki.X.Org for help." But that webpage
>doesn't seem like any support webpage.
>
>
You're right again, this wiki page sucks. While I appreciate that
someone can create something as powerful and intricate as X, without
proper, usable docs it's useless to even the most elite linux guru.
Brandon
From keithp at keithp.com Mon Jun 14 15:03:27 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 14 15:03:48 2004
Subject: [Xorg] New committer process?
In-Reply-To: Your message of "Mon, 14 Jun 2004 20:48:14 BST."
<[email protected]>
Message-ID: <[email protected]>
Around 20 o'clock on Jun 14, Alan Cox wrote:
> Or booby trap the repository.
That falls under the "damage" heading...
> CVS acls can help a lot here - you can limit people to drivers they are
> supposed to be hacking on (which also helps avoid accidents). I'd be
> happier with ACLs, if only because I'll know I can't actually trash
> someone elses work.
Our current CVS setup has people running cvs over ssh through separate
accounts on freedesktop.org. That means the repository itself is writable
by all cvs users. While cvs may respect acls, I'm not sure how to set
things up to prevent people from just editing the repository directly.
Is there some setgid/setuid (yuck) mechanism I'm unaware of? Or should I
be using some other repository access mechanism?
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040614/df7499ac/attach
ment-0001.pgp
From keithp at keithp.com Mon Jun 14 15:06:20 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 14 15:07:38 2004
Subject: [Xorg] VFB in fd.o xserver.
In-Reply-To: Your message of "Mon, 14 Jun 2004 16:11:31 CDT."
<[email protected]>
Message-ID: <[email protected]>
Around 16 o'clock on Jun 14, [email protected] wrote:
> Any idea which branch that might be in?
Xfake is part of the "other" x server project at freedesktop.org. Check
out http://xserver.freedesktop.org.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040614/6075392b/attach
ment.pgp
From nomercy at eutonian.com Mon Jun 14 16:31:34 2004
From: nomercy at eutonian.com (Brandon Mercer)
Date: Mon Jun 14 16:29:58 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Leon Shiman wrote:
>on Mon, 14 Jun 2004 18:00:38 -0400 Brandon Mercer wrote:
>
>
>>Jeremy C. Reed wrote:
>>
>>
>>
>>>On Mon, 14 Jun 2004, Brandon Mercer wrote:
>>>
>>>
>>>
>>>
>>>
>>>>How come you guys weren't this talkative when I posted a question? I
>>>>didn't even get so much as a flame from the group to tell me my message
>>>>was stupid.
>>>>
>>>>
>>>>
>>>>
>>>I guess you are referring to the "Dual Heads with ati 7200" posting. Maybe
>>>because nobody on this list uses dual heads and/or ATI 7200 or they didn't
>>>have time to volunteer to help with it.
>>>
>>>
>>>
>>>
>>Yes, you're right this is the posting I had. Even still, someone should
>>have said SOMETHING about it.
>>
>>
>>
>>>Maybe it is a big and listed in bugzilla already. Or maybe it is a bug and
>>>you should submit it.
>>>
>>>It is interesting that your email's logs said to "Please consult the The
>>>X.Org Foundation support at http://wiki.X.Org for help." But that webpage
>>>doesn't seem like any support webpage.
>>>
>>>
>>>
>>>
>>You're right again, this wiki page sucks. While I appreciate that
>>someone can create something as powerful and intricate as X, without
>>proper, usable docs it's useless to even the most elite linux guru.
>>Brandon
>>
>>
>>
>
>you're very right! i've thought this too for a very long time. are you
>willing to help us systematically to fill this gap??
>
>leon
>
Absolutely, I'd love to help out. Let me know specifically what you're
looking for in this. I think a good starting place would be a 'living'
FAQ. Meaning that it gets updated with new releases, has some structure
and architecture. As users post more questions we can read them and
setup an FAQ. There are several great resources I've used to help me
setup X and do some things like X over ssh, and running X on a remote
machine (like a thin station) that I could compile into a usable FAQ.
Let me know who to submit things to and I'll get on it. Glad to help,
Brandon
From cworth at east.isi.edu Mon Jun 14 17:55:55 2004
From: cworth at east.isi.edu (Carl Worth)
Date: Mon Jun 14 17:56:22 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 14 Jun 2004 19:31:34 -0400, Brandon Mercer wrote:
> Let me know who to submit things to and I'll get on it. Glad to help,
Should be easier than that.
The wiki page should have an Edit button. Just click that, (follow any
registration instructions it gives you), and then you should be able to
help improve this page.
Thanks for your offer to help!
-Carl
From cworth at east.isi.edu Mon Jun 14 18:42:25 2004
From: cworth at east.isi.edu (Carl Worth)
Date: Mon Jun 14 18:42:53 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, 14 Jun 2004 15:03:27 -0700, Keith Packard wrote:
> Is there some setgid/setuid (yuck) mechanism I'm unaware of? Or should I
> be using some other repository access mechanism?
One thing I do on a CVS server I run is to put the following into the
users' .ssh/authorized_keys file, just before their key public key.
no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/bi
n/cvs --allow-root=/cvs server"
This lets the users have CVS access with no shell account. It seems to
work fairly well, but would then require the CVS repository to be
separate from the machine where users do need shell access.
I got that setup from the following page which has several other useful
hints:
http://ioctl.org/unix/cvs/server
-Carl
From elanthis at awesomeplay.com Mon Jun 14 18:57:58 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Mon Jun 14 18:58:01 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 2004-06-14 at 21:42 -0400, Carl Worth wrote:
> This lets the users have CVS access with no shell account. It seems to
> work fairly well, but would then require the CVS repository to be
> separate from the machine where users do need shell access.
Or you could configure a second SSH server that listens on a different
port and stores the user configuration in a root-writable-only location.
Or, if you are one of the rare geniuses that can grok SELinux
configuration, use that to lock things down exactly how you want it.
>
> I got that setup from the following page which has several other useful
> hints:
>
> http://ioctl.org/unix/cvs/server
>
> -Carl
>
>
>
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From eta at lclark.edu Mon Jun 14 19:35:43 2004
From: eta at lclark.edu (Eric Anholt)
Date: Mon Jun 14 19:36:17 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1087266943.873.20.camel@leguin>
On Mon, 2004-06-14 at 11:37, Keith Packard wrote:
> Around 19 o'clock on Jun 14, Ely Levy wrote:
>
> > Isn't SSH safe enough?
> > commiting with SSH sounds preety good way to prevent spoofing IMHO
>
> My question was higher level -- how do we authenticate people we give
> accounts to on the machine in the first place. Right now, we're mostly
> letting each project vette people with informal irc or email
> "authentication"; that works pretty well when you know the people involved,
> otherwise it doesn't work.
>
> Once people have accounts on the machine, SSH had better provide a
> reasonable level of security. I'd certainly be a lot happier with a
> more secure repository though (yes, CVS sucks, but no, we're not switching
> right now).
One thing FreeBSD did was move theri repository to a separate machine
that mere mortals could only access remotely -- no direct editing of the
repository for non-admins. That would make me feel a lot better.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From daniel at freedesktop.org Mon Jun 14 20:15:35 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 14 20:15:35 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 14, 2004 at 03:03:27PM -0700, Keith Packard wrote:
> Around 20 o'clock on Jun 14, Alan Cox wrote:
> > CVS acls can help a lot here - you can limit people to drivers they are
> > supposed to be hacking on (which also helps avoid accidents). I'd be
> > happier with ACLs, if only because I'll know I can't actually trash
> > someone elses work.
>
> Our current CVS setup has people running cvs over ssh through separate
> accounts on freedesktop.org. That means the repository itself is writable
> by all cvs users. While cvs may respect acls, I'm not sure how to set
> things up to prevent people from just editing the repository directly.
Um, maybe Alan meant filesystem-level ACLs, so you can't actually edit
the ,v at all. I'm pretty sure fd.o's current kernel has ACL support.
--
Daniel Stone <[email protected]>
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/20040615/ca4e73c1/attach
ment.pgp
From daniel at freedesktop.org Mon Jun 14 20:16:27 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 14 20:16:27 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 14, 2004 at 09:42:25PM -0400, Carl Worth wrote:
> On Mon, 14 Jun 2004 15:03:27 -0700, Keith Packard wrote:
> > Is there some setgid/setuid (yuck) mechanism I'm unaware of? Or should I
> > be using some other repository access mechanism?
>
> One thing I do on a CVS server I run is to put the following into the
> users' .ssh/authorized_keys file, just before their key public key.
>
> no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/
bin/cvs --allow-root=/cvs server"
>
> This lets the users have CVS access with no shell account. It seems to
> work fairly well, but would then require the CVS repository to be
> separate from the machine where users do need shell access.
Right; fd.o is too much of a general-purpose machine to make that
happen.
--
Daniel Stone <[email protected]>
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/20040615/7d9bc45c/attach
ment.pgp
From daniel at freedesktop.org Mon Jun 14 20:17:45 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 14 20:17:44 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 14, 2004 at 12:53:07PM -0700, Jeremy C. Reed wrote:
> On Mon, 14 Jun 2004, Keith Packard wrote:
> > > Isn't SSH safe enough?
> > > commiting with SSH sounds preety good way to prevent spoofing IMHO
> >
> > My question was higher level -- how do we authenticate people we give
> > accounts to on the machine in the first place. Right now, we're mostly
> > letting each project vette people with informal irc or email
> > "authentication"; that works pretty well when you know the people involved,
> > otherwise it doesn't work.
>
> One of the groups I am a member of requires GPG/PGP keys signed by another
> member already part of the project.
>
> And they have to meet in person (I was told) for the verification.
I'm a part of Debian, which requires this step, but that would really
suck for a community as relatively small as X, to be honest. Luckily, I
went to linux.conf.au and exchanged signatures with keithp, but how else
would I get in, being on the other side of the world from most everyone
else who hacks on X?
--
Daniel Stone <[email protected]>
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/20040615/aacbde01/attach
ment.pgp
From alan at lxorguk.ukuu.org.uk Tue Jun 15 05:36:19 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue Jun 15 06:39:30 2004
Subject: [Xorg] DRI merging
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
> Where DRI is not supported it's not used, why should any other driver be
> forced to work every where?
All the current drivers barring some OS specific things like Linux frame
buffer driver work when DRI isnt available on that platform and fall
gracefully back to 2D with software 3D, including those that when DRI is
available use the DRI layer for 2D.
This is an important part of the XFree/Xorg tradition.
From alan at lxorguk.ukuu.org.uk Tue Jun 15 05:45:37 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue Jun 15 06:48:53 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Llu, 2004-06-14 at 23:03, Keith Packard wrote:
> Our current CVS setup has people running cvs over ssh through separate
> accounts on freedesktop.org. That means the repository itself is writable
> by all cvs users. While cvs may respect acls, I'm not sure how to set
> things up to prevent people from just editing the repository directly.
Linux supports file system acls nowdays (and in 2.6 SELinux roles)
> Is there some setgid/setuid (yuck) mechanism I'm unaware of? Or should I
> be using some other repository access mechanism?
With file system acls you could probably do it without any such changes.
Without that you'd need to do something like
groupadd cvs
chown root.cvs /cvs
chmod 770 /cvs
and make cvs itself setgid cvs. That wouldn't be perfect but the failure
case is where we were anyway.
Most of the value of CVS acls is accident avoidance and policy
enforcement anyway, stopping a change being made that is against policy
but the user didnt know about etc. Just as I know my own root password I
run as a non root user to avoid
nasty messes of my own making.
The elegant solutions involve SELinux and having a "login" and a "cvs"
role which have different right sets. I'm simply not competent enough in
SELinux to help with such a proposal however.
Alan
From eich at pdx.freedesktop.org Tue Jun 15 10:35:23 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Tue Jun 15 10:36:39 2004
Subject: [Xorg] New committer process?
In-Reply-To: [email protected] wrote on Monday, 14 June 2004 at 09:37:09 -0700
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Keith Packard writes:
>
> Around 11 o'clock on Jun 14, Egbert Eich wrote:
>
> > I've tried to take into account discussions we had previously on this and
> > other lists. Please note that this is only a draft and should serve as an
> > RFC. I'm not aware of any comments so far.
>
> Let's have a few comments then.
>
> Given that CVS is completely insecure (anyone with write access can damage
> or destroy the repository), I suggest that we need some minimal process for
> granting write access.
Yes, for the way we handle things this is definitely true.
However This would only apply of someone either screws up on purpose
or is crazy enough to do things that he has no clue about. (You can
only destroy the repository when you access the files directly.)
Frequent backups of the repository would help to lessen the danger
of loosing things in this event.
>
> I don't know what form this should take though; the proposal for
> 'sponsorship' has a lot of benefits, but does tend to shut out people who
> are new on the scene. We might also consider granting access in some kind
I don't understand this. Not giving CVS write access immediately does
not shut out people.
Requiring some minimal proof of the sincerity of the request and the
quality of work before letting people write to CVS does not seem to
be unreasonable to me.
I would expect that anybody who is interested in providing new code
would check out the tree, hack away, come up with an initial implementation,
make it public (mailinglist, bugzilla) and then - if his code seems reasonably
sane - he gets CVS commit access.
> of incremental fashion; with early access limited to 'less sensitive'
I like to keep the process lightweight. Such things can be done by acls
but this would increase the complexity.
> parts of the tree. It would also be nice to have some kind of
> identification for each committer to prevent spoofed access.
>
To spoof access you would have to obtain someones identity.
Do you expect this?
Egbert.
From keith at tungstengraphics.com Tue Jun 15 11:24:06 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Tue Jun 15 11:24:14 2004
Subject: [Xorg] New committer process?
In-Reply-To: <[email protected]>
References: <[email protected]> <E1BZuSL-0005Mx-
[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Egbert Eich wrote:
> Keith Packard writes:
> >
> > Around 11 o'clock on Jun 14, Egbert Eich wrote:
> >
> > > I've tried to take into account discussions we had previously on this and
> > > other lists. Please note that this is only a draft and should serve as an
> > > RFC. I'm not aware of any comments so far.
> >
> > Let's have a few comments then.
> >
> > Given that CVS is completely insecure (anyone with write access can damage
> > or destroy the repository), I suggest that we need some minimal process for
> > granting write access.
>
> Yes, for the way we handle things this is definitely true.
> However This would only apply of someone either screws up on purpose
> or is crazy enough to do things that he has no clue about. (You can
> only destroy the repository when you access the files directly.)
> Frequent backups of the repository would help to lessen the danger
> of loosing things in this event.
>
> >
> > I don't know what form this should take though; the proposal for
> > 'sponsorship' has a lot of benefits, but does tend to shut out people who
> > are new on the scene. We might also consider granting access in some kind
>
> I don't understand this. Not giving CVS write access immediately does
> not shut out people.
> Requiring some minimal proof of the sincerity of the request and the
> quality of work before letting people write to CVS does not seem to
> be unreasonable to me.
> I would expect that anybody who is interested in providing new code
> would check out the tree, hack away, come up with an initial implementation,
> make it public (mailinglist, bugzilla) and then - if his code seems reasonably
> sane - he gets CVS commit access.
This is pretty much how it has worked in the DRI & Mesa tree, and we've been
pretty happy with it. The only time anyone has done anything 'questionable',
they cleared it up themselves shortly afterwards.
I definitely think that CVS write permission should be distinct from direct
ssh access to the repository. I don't see any reason for non-admins to have
that level of access.
One thing I miss from sourceforge is a formalized procedure for adding and
removing developers - by formalized I guess I mean that there was a web page
and you did stuff through that rather than a vague process of emailing people.
Just being able to pull up a list of who did & did not have committer
access was helpful.
Keith
From asterius at airpost.net Tue Jun 15 19:22:16 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Tue Jun 15 19:22:19 2004
Subject: [Xorg] Successfully compiled Kdrive, but...
Message-ID: <[email protected]>
Hi everyone. Some readers might know my troubles compiling Kdrive
with ebuild that Gentoo provides ( and I am not alone). My mouse wasn't
working. Painstakingly searching the web and asking questions on this
mailing list didn't glean any hints except finding out that one person
successfully compiled Kdrive defining host.def file against sources
after failing to compile with Gentoo ebuild ( shame on you Gentoo
developers). I have followed his way and vaola, my Xvesa and Xfbdev are
working. I've build it defining #ProjectRoot /usr/X11R6 while my working
directory was /home/kdrive/xc asuming that all files needed will be
installed in this directory. However I didn't find there any. Then,
I have just copied and tested both servers and as I said they work as
standalone. My qestion is this. While they can work on their own, isn't
it correct that I need shared libraries in /usr/X11R6, includes etc. in
there in order to compile other X apps like mozilla for instance?
Probably I had to " make install " after " make World"? What files(
or directory do I have to copy in my /usr/X11R6 ? Thanks in advance.
Asterius.
From spyderous at gentoo.org Tue Jun 15 19:36:17 2004
From: spyderous at gentoo.org (Donnie Berkholz)
Date: Tue Jun 15 19:36:23 2004
Subject: [Xorg] Successfully compiled Kdrive, but...
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Asterius Pandoras said:
> Hi everyone. Some readers might know my troubles compiling Kdrive
> with ebuild that Gentoo provides ( and I am not alone). My mouse wasn't
> working. Painstakingly searching the web and asking questions on this
> mailing list didn't glean any hints except finding out that one person
> successfully compiled Kdrive defining host.def file against sources
> after failing to compile with Gentoo ebuild ( shame on you Gentoo
> developers).
Works for me. Also that kdrive is old as sand, from back when it was
pulled from XFree86 sources. Please go to xserver.freedesktop.org instead.
If you've got problems with a Gentoo ebuild, please file a Gentoo bug
rather than posting to a generic mailing list.
Thanks,
Donnie
From jaymz at artificial-stupidity.net Tue Jun 15 19:36:47 2004
From: jaymz at artificial-stupidity.net (Jaymz Julian)
Date: Tue Jun 15 19:36:58 2004
Subject: [Xorg] Successfully compiled Kdrive, but...
In-Reply-To: <[email protected]>;
from [email protected] on Tue, Jun 15, 2004 at 06:22:16PM -0800
References: <[email protected]>
Message-ID: <[email protected]>
Do you have a ps/2 mouse? try 'modprobe psmouse'. usb mouse?
try adding -mouse /dev/input/mice to your c ommand line.
-- jaym
Tue, Jun 15, 2004 at 06:22:16PM -0800, Asterius Pandoras wrote:
> Hi everyone. Some readers might know my troubles compiling Kdrive
> with ebuild that Gentoo provides ( and I am not alone). My mouse wasn't
> working. Painstakingly searching the web and asking questions on this
> mailing list didn't glean any hints except finding out that one person
> successfully compiled Kdrive defining host.def file against sources
> after failing to compile with Gentoo ebuild ( shame on you Gentoo
> developers). I have followed his way and vaola, my Xvesa and Xfbdev are
> working. I've build it defining #ProjectRoot /usr/X11R6 while my working
> directory was /home/kdrive/xc asuming that all files needed will be
> installed in this directory. However I didn't find there any. Then,
> I have just copied and tested both servers and as I said they work as
> standalone. My qestion is this. While they can work on their own, isn't
> it correct that I need shared libraries in /usr/X11R6, includes etc. in
> there in order to compile other X apps like mozilla for instance?
> Probably I had to " make install " after " make World"? What files(
> or directory do I have to copy in my /usr/X11R6 ? Thanks in advance.
>
> Asterius.
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
--
--
Jaymz Julian - Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people.
Very few people have `I want to be killed and eaten' on their cards,
so Hannibal is out of a job." - http://cards.sf.net
From eta at lclark.edu Wed Jun 16 02:15:20 2004
From: eta at lclark.edu (Eric Anholt)
Date: Wed Jun 16 02:15:55 2004
Subject: [Xorg] HEADSUP: DRI merge in progress
Message-ID: <1087377320.94770.4.camel@leguin>
Okay, I think I've got a manageable process for doing the DRI merge
ready. It'll be going into the tree over the next hour, if things go
right. Please leave CVS quiet until I give the all-clear.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From eta at lclark.edu Wed Jun 16 03:43:22 2004
From: eta at lclark.edu (Eric Anholt)
Date: Wed Jun 16 03:43:55 2004
Subject: [Xorg] HEADSUP: DRI merged
Message-ID: <1087382601.94770.14.camel@leguin>
OK, it's in the tree, and seems to be working. The build succeeded on
pdx except for http://freedesktop.org/bugzilla/show_bug.cgi?id=757
getting in the way, and it's going successfully on local FreeBSD. I'm
running the same code (r200 driver) from my practice merge that was used
to commit the diffs, so I think things should be ok. Please report
build-related problems to me, or even better, bugzilla and assign them
to [email protected]. Other DRI issues to the standard DRI stuff in
bugzilla.
Notable things this brings in, off the top of my head:
- Mesa 6
- MergedFB for Radeon!
- Many GLX fixes
- Working SiS DRI driver
- Major Radeon and R200 updates
- fbconfigs support
- Beginnings of pbuffer support (indirect only, and only in specific
circumstances).
Notable things this doesn't bring in:
- Mach64 DRI support (insecure)
- Savage DRI support (insecure)
Possible issues I see:
- MergedFB mismerges (I *think* I got it right)
- New DRI modules won't work with old libGL, but this shouldn't be too
major
- X86 asm issues in new DRI driver build - WORKSFORME
- Need i915 DDX brought over and DRI Imakefile glue
- It's development code, but then this is a development branch.
- my lack of sleep
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From spamfrommailing at freax.org Wed Jun 16 03:51:19 2004
From: spamfrommailing at freax.org (Philip Van Hoof)
Date: Wed Jun 16 03:51:18 2004
Subject: [Xorg] XFixes extentions
Message-ID: <1087383080.3623.28.camel@elfeling>
Hi there,
Assuming that I have the FixesExt installed, how as a developer do I
start using the new event "xXFixesSelectionNotifyEvent"?
Note that I don't have much experience with xlib, I do have with Gtk+.
I failed to find samples :(
--
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org
From alexdeucher at gmail.com Wed Jun 16 05:59:25 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Wed Jun 16 05:59:27 2004
Subject: [Xorg] HEADSUP: DRI merged
In-Reply-To: <1087382601.94770.14.camel@leguin>
References: <1087382601.94770.14.camel@leguin>
Message-ID: <[email protected]>
On Wed, 16 Jun 2004 03:43:22 -0700, Eric Anholt <[email protected]> wrote:
>
> OK, it's in the tree, and seems to be working. The build succeeded on
> pdx except for http://freedesktop.org/bugzilla/show_bug.cgi?id=757
> getting in the way, and it's going successfully on local FreeBSD. I'm
> running the same code (r200 driver) from my practice merge that was used
> to commit the diffs, so I think things should be ok. Please report
> build-related problems to me, or even better, bugzilla and assign them
> to [email protected]. Other DRI issues to the standard DRI stuff in
> bugzilla.
>
> Notable things this brings in, off the top of my head:
> - Mesa 6
> - MergedFB for Radeon!
> - Many GLX fixes
> - Working SiS DRI driver
> - Major Radeon and R200 updates
> - fbconfigs support
> - Beginnings of pbuffer support (indirect only, and only in specific
> circumstances).
>
> Notable things this doesn't bring in:
> - Mach64 DRI support (insecure)
> - Savage DRI support (insecure)
>
> Possible issues I see:
> - MergedFB mismerges (I *think* I got it right)
I'll try and check out the tree and give it a test hopefully in the
next few days depending how much free time I can muster. If not, I'll
get to it next week. Also, did this merge include any of ati's new
code drop or just the DRI changes?
Alex
> - New DRI modules won't work with old libGL, but this shouldn't be too
> major
> - X86 asm issues in new DRI driver build - WORKSFORME
> - Need i915 DDX brought over and DRI Imakefile glue
> - It's development code, but then this is a development branch.
> - my lack of sleep
>
> --
> Eric Anholt [email protected]
> http://people.freebsd.org/~anholt/ [email protected]
>
From elylevy-xserver at cs.huji.ac.il Wed Jun 16 07:26:47 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Jun 16 07:26:50 2004
Subject: [Xorg] HEADSUP: DRI merged
Message-ID: <[email protected]>
Hey,
just for my general knowladge:)
what insecure about
- Mach64 DRI support (insecure)
- Savage DRI support (insecure)
how is it diffrent from other dris?
and what's
- fbconfigs support?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 16 Jun 2004, Eric Anholt wrote:
> OK, it's in the tree, and seems to be working. The build succeeded on
> pdx except for http://freedesktop.org/bugzilla/show_bug.cgi?id=757
> getting in the way, and it's going successfully on local FreeBSD. I'm
> running the same code (r200 driver) from my practice merge that was used
> to commit the diffs, so I think things should be ok. Please report
> build-related problems to me, or even better, bugzilla and assign them
> to [email protected]. Other DRI issues to the standard DRI stuff in
> bugzilla.
>
> Notable things this brings in, off the top of my head:
> - Mesa 6
> - MergedFB for Radeon!
> - Many GLX fixes
> - Working SiS DRI driver
> - Major Radeon and R200 updates
> - fbconfigs support
> - Beginnings of pbuffer support (indirect only, and only in specific
> circumstances).
>
> Notable things this doesn't bring in:
> - Mach64 DRI support (insecure)
> - Savage DRI support (insecure)
>
> Possible issues I see:
> - MergedFB mismerges (I *think* I got it right)
> - New DRI modules won't work with old libGL, but this shouldn't be too
> major
> - X86 asm issues in new DRI driver build - WORKSFORME
> - Need i915 DDX brought over and DRI Imakefile glue
> - It's development code, but then this is a development branch.
> - my lack of sleep
>
> --
> Eric Anholt [email protected]
> http://people.freebsd.org/~anholt/ [email protected]
>
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From roland.mainz at nrubsig.org Wed Jun 16 07:50:57 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Wed Jun 16 07:51:21 2004
Subject: [Xorg] HEADSUP: DRI merged
References: <1087382601.94770.14.camel@leguin>
Message-ID: <[email protected]>
Eric Anholt wrote:
>
> OK, it's in the tree, and seems to be working. The build succeeded on
> pdx except for http://freedesktop.org/bugzilla/show_bug.cgi?id=757
I've commented in the bug...
> getting in the way, and it's going successfully on local FreeBSD. I'm
> running the same code (r200 driver) from my practice merge that was used
> to commit the diffs, so I think things should be ok. Please report
> build-related problems to me, or even better, bugzilla and assign them
> to [email protected]. Other DRI issues to the standard DRI stuff in
> bugzilla.
>
> Notable things this brings in, off the top of my head:
> - Mesa 6
> - MergedFB for Radeon!
> - Many GLX fixes
> - Working SiS DRI driver
> - Major Radeon and R200 updates
> - fbconfigs support
> - Beginnings of pbuffer support (indirect only, and only in specific
> circumstances).
>
> Notable things this doesn't bring in:
> - Mach64 DRI support (insecure)
> - Savage DRI support (insecure)
>
> Possible issues I see:
> - MergedFB mismerges (I *think* I got it right)
> - New DRI modules won't work with old libGL, but this shouldn't be too
> major
> - X86 asm issues in new DRI driver build - WORKSFORME
> - Need i915 DDX brought over and DRI Imakefile glue
> - It's development code, but then this is a development branch.
> - my lack of sleep
It seems that the tree does not compile anymore on SuSE8.2:
-- snip --
make[5]: Entering directory
`/home/gismobile/projects/xorg/work2/xc/lib/XvMC/hw/i810'
rm -f I810XvMC.o
gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
-pedantic -Wall -Wpointer-arith -Wundef
-I../../../../exports/include/X11 -I../../../../exports/include
-I../../../../lib/X11 -I../../../../include/extensions
-I../../../../programs/Xserver/hw/xfree86/common
-I../../../../programs/Xserver/hw/xfree86/os-support
-I../../../../programs/Xserver/hw/xfree86/os-support/linux/drm/kernel

-I../../../../programs/Xserver/hw/xfree86/drivers/i810 -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
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL
-DTRUE=1 -DFALSE=0 -DXVENDORNAME='"The X.Org Foundation"'
-DXVENDORNAMESHORT='"X.Org"' -fPIC I810XvMC.c
In file included from I810XvMC.h:44,
from I810XvMC.c:53:
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:39:17:
drm.h: No such file or directory
In file included from I810XvMC.h:44,
from I810XvMC.c:53:
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:222: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:222:
warning: no semicolon at end of struct or union
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232: error:
parse error before '}' token
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232:
warning: type defaults to `int' in declaration of `drmDMAReq'
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232:
warning: type defaults to `int' in declaration of `drmDMAReqPtr'
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232: error:
ISO C forbids data definition with no type or storage class
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:235: error:
parse error before "drm_handle_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:235:
warning: no semicolon at end of struct or union
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239: error:
parse error before '}' token
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239:
warning: type defaults to `int' in declaration of `drmRegion'
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239:
warning: type defaults to `int' in declaration of `drmRegionPtr'
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239: error:
ISO C forbids data definition with no type or storage class
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:492: error:
parse error before "drm_magic_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:496: error:
parse error before "drm_handle_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:516: error:
parse error before "drm_magic_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:518: error:
parse error before "drm_handle_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:523: error:
parse error before "drm_handle_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:524: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:531: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:532: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:534: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:536: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:537: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:538: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:539: error:
parse error before '*' token
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:539:
warning: type defaults to `int' in declaration of
`drmGetReservedContextList'
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:539: error:
ISO C forbids data definition with no type or storage class
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:540: error:
parse error before '*' token
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:541: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:542: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:543: error:
parse error before "drm_drawable_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:544: error:
parse error before "drm_drawable_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:555: error:
parse error before "drm_handle_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:562: error:
parse error before "drmDMAReqPtr"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:565: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:567: error:
parse error before "drm_context_t"
../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:569: error:
parse error before "drm_context_t"
In file included from I810XvMC.c:53:
I810XvMC.h:89: error: parse error before "drmHandle"
I810XvMC.h:89: warning: no semicolon at end of struct or union
I810XvMC.h:92: error: parse error before '}' token
I810XvMC.h:92: warning: type defaults to `int' in declaration of
`i810XvMCDrmMap'
I810XvMC.h:92: warning: type defaults to `int' in declaration of
`i810XvMCDrmMapPtr'
I810XvMC.h:92: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:100: error: parse error before "i810XvMCDrmMap"
I810XvMC.h:100: warning: no semicolon at end of struct or union
I810XvMC.h:101: warning: type defaults to `int' in declaration of
`surfaces'
I810XvMC.h:101: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:103: error: parse error before "drmcontext"
I810XvMC.h:103: warning: type defaults to `int' in declaration of
`drmcontext'
I810XvMC.h:103: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:121: error: parse error before '}' token
I810XvMC.h:121: warning: type defaults to `int' in declaration of
`i810XvMCContext'
I810XvMC.h:121: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:147: error: parse error before "drmHandle"
I810XvMC.h:147: warning: no semicolon at end of struct or union
I810XvMC.h:149: error: parse error before '*' token
I810XvMC.h:149: warning: type defaults to `int' in declaration of
`privContext'
I810XvMC.h:149: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:150: error: parse error before '}' token
I810XvMC.h:150: warning: type defaults to `int' in declaration of
`i810XvMCSurface'
I810XvMC.h:150: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:167: error: parse error before "drmHandle"
I810XvMC.h:167: warning: no semicolon at end of struct or union
I810XvMC.h:168: error: conflicting types for `offsets'
I810XvMC.h:148: error: previous declaration of `offsets'
I810XvMC.h:170: error: parse error before '*' token
I810XvMC.h:170: warning: type defaults to `int' in declaration of
`privContext'
I810XvMC.h:170: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:171: error: parse error before '}' token
I810XvMC.h:171: warning: type defaults to `int' in declaration of
`i810XvMCSubpicture'
I810XvMC.h:171: error: ISO C forbids data definition with no type or
storage class
I810XvMC.h:362: error: parse error before '*' token
I810XvMC.h:363: error: parse error before '*' token
I810XvMC.c:69: error: parse error before '*' token
I810XvMC.c: In function `i810_get_free_buffer':
I810XvMC.c:76: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:76: error: (Each undeclared identifier is reported only once
I810XvMC.c:76: error: for each function it appears in.)
I810XvMC.c: At top level:
I810XvMC.c:93: error: parse error before '*' token
I810XvMC.c: In function `i810_free_privContext':
I810XvMC.c:95: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c: In function `XvMCCreateContext':
I810XvMC.c:132: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:133: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:175: error: parse error before ')' token
I810XvMC.c: In function `XvMCDestroyContext':
I810XvMC.c:379: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:387: error: parse error before ')' token
I810XvMC.c: In function `XvMCCreateSurface':
I810XvMC.c:429: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:430: error: `pI810Surface' undeclared (first use in this
function)
I810XvMC.c:431: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:439: error: parse error before ')' token
I810XvMC.c:445: error: parse error before ')' token
I810XvMC.c:449: error: parse error before ')' token
I810XvMC.c: In function `XvMCDestroySurface':
I810XvMC.c:595: error: `pI810Surface' undeclared (first use in this
function)
I810XvMC.c:596: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:605: error: parse error before ')' token
I810XvMC.c:609: error: parse error before ')' token
I810XvMC.c: In function `dp':
I810XvMC.c:712: warning: comparison between signed and unsigned
I810XvMC.c: At top level:
I810XvMC.c:962: error: parse error before '*' token
I810XvMC.c: In function `dispatchYContext':
I810XvMC.c:970: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:976: error: `privTarget' undeclared (first use in this
function)
I810XvMC.c:981: error: `privPast' undeclared (first use in this
function)
I810XvMC.c:986: error: `privFuture' undeclared (first use in this
function)
I810XvMC.c: In function `renderFieldinField':
I810XvMC.c:1212: warning: comparison between signed and unsigned
I810XvMC.c: In function `render16x8inField':
I810XvMC.c:1322: warning: comparison between signed and unsigned
I810XvMC.c:1346: warning: comparison between signed and unsigned
I810XvMC.c: In function `XvMCRenderSurface':
I810XvMC.c:2431: error: `privTarget' undeclared (first use in this
function)
I810XvMC.c:2432: error: `privFuture' undeclared (first use in this
function)
I810XvMC.c:2433: error: `privPast' undeclared (first use in this
function)
I810XvMC.c:2434: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:2437: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:2451: error: parse error before ')' token
I810XvMC.c:2458: error: parse error before ')' token
I810XvMC.c:2481: error: parse error before ')' token
I810XvMC.c:2509: error: parse error before ')' token
I810XvMC.c:2521: warning: comparison between signed and unsigned
I810XvMC.c: In function `XvMCPutSurface':
I810XvMC.c:2824: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:2825: error: `pI810Surface' undeclared (first use in this
function)
I810XvMC.c:2826: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:2853: error: parse error before ')' token
I810XvMC.c:2854: error: parse error before ')' token
I810XvMC.c:2901: warning: comparison between signed and unsigned
I810XvMC.c:2906: warning: comparison between signed and unsigned
I810XvMC.c:2911: warning: comparison between signed and unsigned
I810XvMC.c:2916: warning: comparison between signed and unsigned
I810XvMC.c: In function `XvMCGetSurfaceStatus':
I810XvMC.c:3302: error: `privSurface' undeclared (first use in this
function)
I810XvMC.c:3303: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3304: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c: In function `XvMCHideSurface':
I810XvMC.c:3377: error: `pI810Surface' undeclared (first use in this
function)
I810XvMC.c:3378: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3379: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:3396: error: parse error before ')' token
I810XvMC.c:3410: error: parse error before ')' token
I810XvMC.c: In function `XvMCCreateSubpicture':
I810XvMC.c:3477: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3478: error: `pI810Subpicture' undeclared (first use in this
function)
I810XvMC.c:3479: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:3487: error: parse error before ')' token
I810XvMC.c:3501: error: parse error before ')' token
I810XvMC.c:3506: error: parse error before ')' token
I810XvMC.c: In function `XvMCClearSubpicture':
I810XvMC.c:3608: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3609: error: `pI810Subpicture' undeclared (first use in this
function)
I810XvMC.c:3610: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:3619: error: parse error before ')' token
I810XvMC.c:3621: error: parse error before ')' token
I810XvMC.c: In function `XvMCCompositeSubpicture':
I810XvMC.c:3664: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3665: error: `pI810Subpicture' undeclared (first use in this
function)
I810XvMC.c:3666: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:3675: error: parse error before ')' token
I810XvMC.c:3677: error: parse error before ')' token
I810XvMC.c: In function `XvMCDestroySubpicture':
I810XvMC.c:3724: error: `pI810Subpicture' undeclared (first use in this
function)
I810XvMC.c:3725: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3733: error: parse error before ')' token
I810XvMC.c:3735: error: parse error before ')' token
I810XvMC.c: In function `XvMCSetSubpicturePalette':
I810XvMC.c:3768: error: `privSubpicture' undeclared (first use in this
function)
I810XvMC.c:3769: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:3777: error: parse error before ')' token
I810XvMC.c: In function `XvMCBlendSubpicture2':
I810XvMC.c:3859: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:3860: error: `privSubpicture' undeclared (first use in this
function)
I810XvMC.c:3861: error: `privTarget' undeclared (first use in this
function)
I810XvMC.c:3862: error: `privSource' undeclared (first use in this
function)
I810XvMC.c:3863: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c:3886: error: parse error before ')' token
I810XvMC.c:3888: error: parse error before ')' token
I810XvMC.c:3896: error: parse error before ')' token
I810XvMC.c:3901: error: parse error before ')' token
I810XvMC.c: In function `XvMCGetSubpictureStatus':
I810XvMC.c:4283: error: `privSubpicture' undeclared (first use in this
function)
I810XvMC.c:4284: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:4293: error: parse error before ')' token
I810XvMC.c:4295: error: parse error before ')' token
I810XvMC.c: In function `XvMCQueryAttributes':
I810XvMC.c:4343: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c:4344: warning: ISO C89 forbids mixed declarations and code
I810XvMC.c: In function `XvMCSetAttribute':
I810XvMC.c:4399: error: `pI810XvMC' undeclared (first use in this
function)
I810XvMC.c: In function `XvMCGetAttribute':
I810XvMC.c:4470: error: `pI810XvMC' undeclared (first use in this
function)
make[5]: *** [I810XvMC.o] Error 1
make[5]: Leaving directory
`/home/gismobile/projects/xorg/work2/xc/lib/XvMC/hw/i810'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/home/gismobile/projects/xorg/work2/xc/lib/XvMC'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/gismobile/projects/xorg/work2/xc/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/gismobile/projects/xorg/work2/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/home/gismobile/projects/xorg/work2/xc'
make: *** [World] Error 2
-- snip --
;-(
----
Bye,
Roland
P.S.: It seems that a workaround is to place |#define BuildXvExt NO|
in xc/config/cf/host.def
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From mfrey at pepper.com Wed Jun 16 08:06:42 2004
From: mfrey at pepper.com (Michael Frey)
Date: Wed Jun 16 08:06:44 2004
Subject: [Xorg] Xfbdev acceleration.
Message-ID: <[email protected]>
Hello,
I have been using Xfbdev from the XFree86 branch for some time. I
added acceleration code to fbdev for an Epson chip I am using. It
works great.
I want to move to the freedesktop.org Xfbdev server and I am having
trouble moving my blt code over. I noticed that the new server uses
offscreen pixmaps for acceleration.
My video card does not have enough memory for offscreen pixmaps and
only has enough memory for the on-screen frame buffer. If I fill out
in fbinit.c my functions for acceleration they never get called because
in fbdev.c
screen->memory_size = 0;
screen->off_screen_base = 0;
I tried changing the memory setting to be the memory size of my board
but with no luck.
Is there a way to enable acceleration without using offscreen pixmaps
the way the old kdrive used to do it?
Thanks in advance,
Michael Frey


From charlie at vexi.org Wed Jun 16 10:11:40 2004
From: charlie at vexi.org (Charles Goodwin)
Date: Wed Jun 16 10:08:42 2004
Subject: [Xorg] New commiter process?
Message-ID: <[email protected]>
I hope you don't mind, but I'd like to interject in order to do a bit of
software evangelizing as it answers the problem of having to trust new
committers.
CVS is bad. It really is. And you can't appreciate how bad it is until
you use something better. And with a project like XServer where there
are different groups with different interests, there is nothing better
than distributed SCM [Source Code Management].
Two alternatives are monotone [1] and GNU Arch [2], but the SCM tool I'm
going to focus on is the one we [3] use, Darcs [4].
All repos are hosted over http, so it's incredibly simple to share your
patches with others, and commits can be done directly over SSH (to your
repo), FTP (for the SSH-less), or indirectly through email (to repos
that you have no access to).
"Patches"; Darcs is patch based. Everything is a patch and a repo is a
collection of chronologically applied patches. Because everything is a
patch, you can easily shoot back through your history and unpull patches
or apply patches other people have written. A darcs repo is incredibly
mallable, and it makes bringing in a host of other people's updates a
complete doddle.
Back to the original point, the problem with trusting new committers.
Well, as darcs is hosted over http, and accessed using SSH (or ftp for
the ssh-limited), security issues vanish. If somebody needs their own
repo you can give them a fd.o account and a small chunk of webspace.
Otherwise each individual interest (eg. cygwin) would be responsbile for
handling their own committer approval and anybody could contribute
easily without any commit access to any official repo: getting their
patch would be a simple "darcs pull http://homepage.com/xorg" away.
The great thing about distributed SCM tools like darcs is you spend less
time messing around with branches and other CVS-esque problems and more
time just doing the code and playing with other people's patches.
I would go on, but the darcs manual is good and I already wrote a how-to
on darcs [5] and I'm sure I've gone on for too long already. I know
it's not "simple" to change away from CVS (people need the new software,
everything on fd.o is set up for CVS, etc etc) but it is worth the
effort and you'll get a great return on your investment of energy. So I
would urge you to consider Darcs or another distributed SCM tool as an
option to solve problems like "who to give access to" as well as an
improved development environment. CVS is horrid after using Darcs.
And no, I'm not affiliated with Darcs in any way. We have just had so
much success with it that I like to do my bit and help promote it. ;)
The only caveat with Darcs is that it's written in Haskell and hence has
a few awkward (as in not-widely-installed) dependencies, but it is a
small price to pay for the benefits it gives you. And it goes without
saying that it's portable (works in Windows/Linux/Mac just fine).
- Charlie
Charles Goodwin <[email protected]>
Online @ www.charlietech.com
[1] Monotone:- www.venge.net/monotone/
[2] GNU Arch:- www.gnu.org/software/gnu-arch/
[3] "We" are the Vexi Project:- www.vexi.org
[4] Darcs:- www.abridgegame.org/darcs
[5] My Darcs How-to:- http://forums.gentoo.org/viewtopic.php?t=137097
From charlie at vexi.org Wed Jun 16 10:42:24 2004
From: charlie at vexi.org (Charles Goodwin)
Date: Wed Jun 16 10:39:20 2004
Subject: [Xorg] New commiter process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Wed, 2004-06-16 at 13:14 -0400, Sean Middleditch wrote:
> Keith very very specifically said they are *not* switching off CVS
> anytime soon. Trust me, we've heard the same "CVS sucks" argument over,
> and over, and over, and over. Likewise, we've heard the "this is why
> SCM [foo] rules so much" argument for every SCM in existence way more
> times than is necessary. We all know everything there is to know about
> Subversion, Darcs, Bitkeeper, GNU Arch, etc. (Most of us are bright
> enough to use one of those for our own projects. ~,^ )
No apology necessary and, well, of course you guys know about 'em. It
was a bit patronising of me to assume otherwise. Sorry! ;)
> Xorg isn't switching anytime soon though for purely logistic reasons,
The rebuttal to that would be that a distributed SCM tool is better
"logistically" than CVS, but sheesh some say Emacs is better than Vi.
> so the argument is completely pointless. Sorry.
Oh well. "Nice try" me. Back to lurker mode...
--
- Charlie
Charles Goodwin <[email protected]>
Online @ www.charlietech.com
From eta at lclark.edu Wed Jun 16 11:47:15 2004
From: eta at lclark.edu (Eric Anholt)
Date: Wed Jun 16 11:47:51 2004
Subject: [Xorg] HEADSUP: DRI merged
In-Reply-To: <[email protected]>
References: <1087382601.94770.14.camel@leguin>
<[email protected]>
Message-ID: <1087411634.859.55.camel@leguin>
On Wed, 2004-06-16 at 05:59, Alex Deucher wrote:
> On Wed, 16 Jun 2004 03:43:22 -0700, Eric Anholt <[email protected]> wrote:
> >
> > OK, it's in the tree, and seems to be working. The build succeeded on
> > pdx except for http://freedesktop.org/bugzilla/show_bug.cgi?id=757
> > getting in the way, and it's going successfully on local FreeBSD. I'm
> > running the same code (r200 driver) from my practice merge that was used
> > to commit the diffs, so I think things should be ok. Please report
> > build-related problems to me, or even better, bugzilla and assign them
> > to [email protected]. Other DRI issues to the standard DRI stuff in
> > bugzilla.
> >
> > Notable things this brings in, off the top of my head:
> > - Mesa 6
> > - MergedFB for Radeon!
> > - Many GLX fixes
> > - Working SiS DRI driver
> > - Major Radeon and R200 updates
> > - fbconfigs support
> > - Beginnings of pbuffer support (indirect only, and only in specific
> > circumstances).
> >
> > Notable things this doesn't bring in:
> > - Mach64 DRI support (insecure)
> > - Savage DRI support (insecure)
> >
> > Possible issues I see:
> > - MergedFB mismerges (I *think* I got it right)
>
> I'll try and check out the tree and give it a test hopefully in the
> next few days depending how much free time I can muster. If not, I'll
> get to it next week. Also, did this merge include any of ati's new
> code drop or just the DRI changes?
Nope, this was just update -jDRI-XFree86-4_3_99_12-merge
-jDRI-trunk-20040613
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From hiryu at audioseek.net Wed Jun 16 12:02:47 2004
From: hiryu at audioseek.net (Cameron)
Date: Wed Jun 16 11:50:34 2004
Subject: [Xorg] kdrive compilation fails
Message-ID: <[email protected]>
I get this following error:
mgadraw.c:29:25: g400_common.h: No such file or directory
mgadraw.c: In function `mgaDrawInit':
mgadraw.c:255: error: `mgaPrepareBlend' undeclared (first use in this
function)
mgadraw.c:255: error: (Each undeclared identifier is reported only once
mgadraw.c:255: error: for each function it appears in.)
mgadraw.c:256: error: `mgaBlend' undeclared (first use in this function)
mgadraw.c:257: error: `mgaDoneBlend' undeclared (first use in this function)
mgadraw.c:258: error: `mgaPrepareComposite' undeclared (first use in this
function)
mgadraw.c:259: error: `mgaComposite' undeclared (first use in this function)
mgadraw.c:260: error: `mgaDoneComposite' undeclared (first use in this
function)
mgadraw.c: At top level:
mgadraw.c:228: warning: `mgaUploadToScreen' defined but not used
make[3]: *** [mgadraw.o] Error 1
make[3]: Leaving directory `/usr/src/xserver/xserver/hw/kdrive/mga'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/xserver/xserver/hw/kdrive'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/xserver/xserver/hw'
make: *** [all-recursive] Error 1
I did a locate g400_common.h, it is not found on my system at all. So maybe
someone forgot to submit that file. :)
-Cameron
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From eta at lclark.edu Wed Jun 16 11:50:50 2004
From: eta at lclark.edu (Eric Anholt)
Date: Wed Jun 16 11:51:23 2004
Subject: [Xorg] HEADSUP: DRI merged
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1087411849.859.60.camel@leguin>
On Wed, 2004-06-16 at 07:26, Ely Levy wrote:
> Hey,
>
> just for my general knowladge:)
> what insecure about
> - Mach64 DRI support (insecure)
> - Savage DRI support (insecure)
> how is it diffrent from other dris?
Enabling them is essentially "local root hole for anyone who can use the
DRI" because the DMA capabilities of the card could be used to scrape
physical memory for info. I might note that by default the DRI sets the
modes on /dev/dri such that only root can use it anyway, but hints for
Section "DRI" are so popular that basically everyone uses them without
knowing what it could mean (which, according to our current standards
for security of released drivers, is "DRI users can hang the machine").
> and what's
> - fbconfigs support?
GL stuff related to visuals. A requirement for pbuffers.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From eta at lclark.edu Wed Jun 16 12:18:35 2004
From: eta at lclark.edu (Eric Anholt)
Date: Wed Jun 16 12:19:10 2004
Subject: [Xorg] HEADSUP: DRI merged
In-Reply-To: <[email protected]>
References: <1087382601.94770.14.camel@leguin> <[email protected]>
Message-ID: <1087413514.859.63.camel@leguin>
On Wed, 2004-06-16 at 07:50, Roland Mainz wrote:
> It seems that the tree does not compile anymore on SuSE8.2:
> -- snip --
> make[5]: Entering directory
> `/home/gismobile/projects/xorg/work2/xc/lib/XvMC/hw/i810'
> rm -f I810XvMC.o
> gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> -pedantic -Wall -Wpointer-arith -Wundef
> -I../../../../exports/include/X11 -I../../../../exports/include
> -I../../../../lib/X11 -I../../../../include/extensions
> -I../../../../programs/Xserver/hw/xfree86/common
> -I../../../../programs/Xserver/hw/xfree86/os-support
> -I../../../../programs/Xserver/hw/xfree86/os-support/linux/drm/kernel

> -I../../../../programs/Xserver/hw/xfree86/drivers/i810 -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
> -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL
> -DTRUE=1 -DFALSE=0 -DXVENDORNAME='"The X.Org Foundation"'
> -DXVENDORNAMESHORT='"X.Org"' -fPIC I810XvMC.c
> In file included from I810XvMC.h:44,
> from I810XvMC.c:53:
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:39:17:
> drm.h: No such file or directory
...
> I810XvMC.c: In function `XvMCGetAttribute':
> I810XvMC.c:4470: error: `pI810XvMC' undeclared (first use in this
> function)
> make[5]: *** [I810XvMC.o] Error 1
> make[5]: Leaving directory
> `/home/gismobile/projects/xorg/work2/xc/lib/XvMC/hw/i810'
> make[4]: *** [all] Error 2
> make[4]: Leaving directory
> `/home/gismobile/projects/xorg/work2/xc/lib/XvMC'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory `/home/gismobile/projects/xorg/work2/xc/lib'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/gismobile/projects/xorg/work2/xc'
> make[1]: *** [World] Error 2
> make[1]: Leaving directory `/home/gismobile/projects/xorg/work2/xc'
> make: *** [World] Error 2
> -- snip --
Should be fixed now. Thanks!
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From carl at personnelware.com Wed Jun 16 12:45:52 2004
From: carl at personnelware.com (Carl Karsten)
Date: Wed Jun 16 12:42:04 2004
Subject: [Xorg] HEADSUP: DRI merged
References: <1087382601.94770.14.camel@leguin> <[email protected]>
Message-ID: <1e4401c453da$88f17d00$1e01a8c0@cnt496>
Same thing for me:
Gentoo
Linux LinuxBook1 2.6.7-rc3-bk5 #1 Mon Jun 14 18:16:03 GMT 2004 i686 Celeron
(Coppermine) GenuineIntel GNU/Linux
Currently empty xc/config/cf/host.def - I'll try #define BuildXvExt NO
Carl K
----- Original Message -----
From: "Roland Mainz" <[email protected]>
To: "Eric Anholt" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, June 16, 2004 9:50 AM
Subject: Re: [Xorg] HEADSUP: DRI merged
> Eric Anholt wrote:
> >
> > OK, it's in the tree, and seems to be working. The build succeeded on
> > pdx except for http://freedesktop.org/bugzilla/show_bug.cgi?id=757
>
> I've commented in the bug...
>
> > getting in the way, and it's going successfully on local FreeBSD. I'm
> > running the same code (r200 driver) from my practice merge that was used
> > to commit the diffs, so I think things should be ok. Please report
> > build-related problems to me, or even better, bugzilla and assign them
> > to [email protected]. Other DRI issues to the standard DRI stuff in
> > bugzilla.
> >
> > Notable things this brings in, off the top of my head:
> > - Mesa 6
> > - MergedFB for Radeon!
> > - Many GLX fixes
> > - Working SiS DRI driver
> > - Major Radeon and R200 updates
> > - fbconfigs support
> > - Beginnings of pbuffer support (indirect only, and only in specific
> > circumstances).
> >
> > Notable things this doesn't bring in:
> > - Mach64 DRI support (insecure)
> > - Savage DRI support (insecure)
> >
> > Possible issues I see:
> > - MergedFB mismerges (I *think* I got it right)
> > - New DRI modules won't work with old libGL, but this shouldn't be too
> > major
> > - X86 asm issues in new DRI driver build - WORKSFORME
> > - Need i915 DDX brought over and DRI Imakefile glue
> > - It's development code, but then this is a development branch.
> > - my lack of sleep
>
> It seems that the tree does not compile anymore on SuSE8.2:
> -- snip --
> make[5]: Entering directory
> `/home/gismobile/projects/xorg/work2/xc/lib/XvMC/hw/i810'
> rm -f I810XvMC.o
> gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi
> -pedantic -Wall -Wpointer-arith -Wundef
> -I../../../../exports/include/X11 -I../../../../exports/include
> -I../../../../lib/X11 -I../../../../include/extensions
> -I../../../../programs/Xserver/hw/xfree86/common
> -I../../../../programs/Xserver/hw/xfree86/os-support
> -I../../../../programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
> -I../../../../programs/Xserver/hw/xfree86/drivers/i810 -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
> -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RETURNS_NULL
> -DTRUE=1 -DFALSE=0 -DXVENDORNAME='"The X.Org Foundation"'
> -DXVENDORNAMESHORT='"X.Org"' -fPIC I810XvMC.c
> In file included from I810XvMC.h:44,
> from I810XvMC.c:53:
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:39:17:
> drm.h: No such file or directory
> In file included from I810XvMC.h:44,
> from I810XvMC.c:53:
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:222: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:222:
> warning: no semicolon at end of struct or union
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232: error:
> parse error before '}' token
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232:
> warning: type defaults to `int' in declaration of `drmDMAReq'
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232:
> warning: type defaults to `int' in declaration of `drmDMAReqPtr'
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:232: error:
> ISO C forbids data definition with no type or storage class
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:235: error:
> parse error before "drm_handle_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:235:
> warning: no semicolon at end of struct or union
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239: error:
> parse error before '}' token
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239:
> warning: type defaults to `int' in declaration of `drmRegion'
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239:
> warning: type defaults to `int' in declaration of `drmRegionPtr'
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:239: error:
> ISO C forbids data definition with no type or storage class
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:492: error:
> parse error before "drm_magic_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:496: error:
> parse error before "drm_handle_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:516: error:
> parse error before "drm_magic_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:518: error:
> parse error before "drm_handle_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:523: error:
> parse error before "drm_handle_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:524: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:531: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:532: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:534: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:536: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:537: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:538: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:539: error:
> parse error before '*' token
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:539:
> warning: type defaults to `int' in declaration of
> `drmGetReservedContextList'
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:539: error:
> ISO C forbids data definition with no type or storage class
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:540: error:
> parse error before '*' token
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:541: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:542: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:543: error:
> parse error before "drm_drawable_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:544: error:
> parse error before "drm_drawable_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:555: error:
> parse error before "drm_handle_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:562: error:
> parse error before "drmDMAReqPtr"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:565: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:567: error:
> parse error before "drm_context_t"
> ../../../../programs/Xserver/hw/xfree86/os-support/xf86drm.h:569: error:
> parse error before "drm_context_t"
> In file included from I810XvMC.c:53:
> I810XvMC.h:89: error: parse error before "drmHandle"
> I810XvMC.h:89: warning: no semicolon at end of struct or union
> I810XvMC.h:92: error: parse error before '}' token
> I810XvMC.h:92: warning: type defaults to `int' in declaration of
> `i810XvMCDrmMap'
> I810XvMC.h:92: warning: type defaults to `int' in declaration of
> `i810XvMCDrmMapPtr'
> I810XvMC.h:92: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:100: error: parse error before "i810XvMCDrmMap"
> I810XvMC.h:100: warning: no semicolon at end of struct or union
> I810XvMC.h:101: warning: type defaults to `int' in declaration of
> `surfaces'
> I810XvMC.h:101: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:103: error: parse error before "drmcontext"
> I810XvMC.h:103: warning: type defaults to `int' in declaration of
> `drmcontext'
> I810XvMC.h:103: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:121: error: parse error before '}' token
> I810XvMC.h:121: warning: type defaults to `int' in declaration of
> `i810XvMCContext'
> I810XvMC.h:121: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:147: error: parse error before "drmHandle"
> I810XvMC.h:147: warning: no semicolon at end of struct or union
> I810XvMC.h:149: error: parse error before '*' token
> I810XvMC.h:149: warning: type defaults to `int' in declaration of
> `privContext'
> I810XvMC.h:149: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:150: error: parse error before '}' token
> I810XvMC.h:150: warning: type defaults to `int' in declaration of
> `i810XvMCSurface'
> I810XvMC.h:150: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:167: error: parse error before "drmHandle"
> I810XvMC.h:167: warning: no semicolon at end of struct or union
> I810XvMC.h:168: error: conflicting types for `offsets'
> I810XvMC.h:148: error: previous declaration of `offsets'
> I810XvMC.h:170: error: parse error before '*' token
> I810XvMC.h:170: warning: type defaults to `int' in declaration of
> `privContext'
> I810XvMC.h:170: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:171: error: parse error before '}' token
> I810XvMC.h:171: warning: type defaults to `int' in declaration of
> `i810XvMCSubpicture'
> I810XvMC.h:171: error: ISO C forbids data definition with no type or
> storage class
> I810XvMC.h:362: error: parse error before '*' token
> I810XvMC.h:363: error: parse error before '*' token
> I810XvMC.c:69: error: parse error before '*' token
> I810XvMC.c: In function `i810_get_free_buffer':
> I810XvMC.c:76: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:76: error: (Each undeclared identifier is reported only once
> I810XvMC.c:76: error: for each function it appears in.)
> I810XvMC.c: At top level:
> I810XvMC.c:93: error: parse error before '*' token
> I810XvMC.c: In function `i810_free_privContext':
> I810XvMC.c:95: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c: In function `XvMCCreateContext':
> I810XvMC.c:132: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:133: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:175: error: parse error before ')' token
> I810XvMC.c: In function `XvMCDestroyContext':
> I810XvMC.c:379: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:387: error: parse error before ')' token
> I810XvMC.c: In function `XvMCCreateSurface':
> I810XvMC.c:429: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:430: error: `pI810Surface' undeclared (first use in this
> function)
> I810XvMC.c:431: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:439: error: parse error before ')' token
> I810XvMC.c:445: error: parse error before ')' token
> I810XvMC.c:449: error: parse error before ')' token
> I810XvMC.c: In function `XvMCDestroySurface':
> I810XvMC.c:595: error: `pI810Surface' undeclared (first use in this
> function)
> I810XvMC.c:596: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:605: error: parse error before ')' token
> I810XvMC.c:609: error: parse error before ')' token
> I810XvMC.c: In function `dp':
> I810XvMC.c:712: warning: comparison between signed and unsigned
> I810XvMC.c: At top level:
> I810XvMC.c:962: error: parse error before '*' token
> I810XvMC.c: In function `dispatchYContext':
> I810XvMC.c:970: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:976: error: `privTarget' undeclared (first use in this
> function)
> I810XvMC.c:981: error: `privPast' undeclared (first use in this
> function)
> I810XvMC.c:986: error: `privFuture' undeclared (first use in this
> function)
> I810XvMC.c: In function `renderFieldinField':
> I810XvMC.c:1212: warning: comparison between signed and unsigned
> I810XvMC.c: In function `render16x8inField':
> I810XvMC.c:1322: warning: comparison between signed and unsigned
> I810XvMC.c:1346: warning: comparison between signed and unsigned
> I810XvMC.c: In function `XvMCRenderSurface':
> I810XvMC.c:2431: error: `privTarget' undeclared (first use in this
> function)
> I810XvMC.c:2432: error: `privFuture' undeclared (first use in this
> function)
> I810XvMC.c:2433: error: `privPast' undeclared (first use in this
> function)
> I810XvMC.c:2434: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:2437: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:2451: error: parse error before ')' token
> I810XvMC.c:2458: error: parse error before ')' token
> I810XvMC.c:2481: error: parse error before ')' token
> I810XvMC.c:2509: error: parse error before ')' token
> I810XvMC.c:2521: warning: comparison between signed and unsigned
> I810XvMC.c: In function `XvMCPutSurface':
> I810XvMC.c:2824: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:2825: error: `pI810Surface' undeclared (first use in this
> function)
> I810XvMC.c:2826: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:2853: error: parse error before ')' token
> I810XvMC.c:2854: error: parse error before ')' token
> I810XvMC.c:2901: warning: comparison between signed and unsigned
> I810XvMC.c:2906: warning: comparison between signed and unsigned
> I810XvMC.c:2911: warning: comparison between signed and unsigned
> I810XvMC.c:2916: warning: comparison between signed and unsigned
> I810XvMC.c: In function `XvMCGetSurfaceStatus':
> I810XvMC.c:3302: error: `privSurface' undeclared (first use in this
> function)
> I810XvMC.c:3303: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3304: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c: In function `XvMCHideSurface':
> I810XvMC.c:3377: error: `pI810Surface' undeclared (first use in this
> function)
> I810XvMC.c:3378: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3379: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:3396: error: parse error before ')' token
> I810XvMC.c:3410: error: parse error before ')' token
> I810XvMC.c: In function `XvMCCreateSubpicture':
> I810XvMC.c:3477: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3478: error: `pI810Subpicture' undeclared (first use in this
> function)
> I810XvMC.c:3479: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:3487: error: parse error before ')' token
> I810XvMC.c:3501: error: parse error before ')' token
> I810XvMC.c:3506: error: parse error before ')' token
> I810XvMC.c: In function `XvMCClearSubpicture':
> I810XvMC.c:3608: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3609: error: `pI810Subpicture' undeclared (first use in this
> function)
> I810XvMC.c:3610: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:3619: error: parse error before ')' token
> I810XvMC.c:3621: error: parse error before ')' token
> I810XvMC.c: In function `XvMCCompositeSubpicture':
> I810XvMC.c:3664: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3665: error: `pI810Subpicture' undeclared (first use in this
> function)
> I810XvMC.c:3666: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:3675: error: parse error before ')' token
> I810XvMC.c:3677: error: parse error before ')' token
> I810XvMC.c: In function `XvMCDestroySubpicture':
> I810XvMC.c:3724: error: `pI810Subpicture' undeclared (first use in this
> function)
> I810XvMC.c:3725: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3733: error: parse error before ')' token
> I810XvMC.c:3735: error: parse error before ')' token
> I810XvMC.c: In function `XvMCSetSubpicturePalette':
> I810XvMC.c:3768: error: `privSubpicture' undeclared (first use in this
> function)
> I810XvMC.c:3769: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:3777: error: parse error before ')' token
> I810XvMC.c: In function `XvMCBlendSubpicture2':
> I810XvMC.c:3859: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:3860: error: `privSubpicture' undeclared (first use in this
> function)
> I810XvMC.c:3861: error: `privTarget' undeclared (first use in this
> function)
> I810XvMC.c:3862: error: `privSource' undeclared (first use in this
> function)
> I810XvMC.c:3863: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c:3886: error: parse error before ')' token
> I810XvMC.c:3888: error: parse error before ')' token
> I810XvMC.c:3896: error: parse error before ')' token
> I810XvMC.c:3901: error: parse error before ')' token
> I810XvMC.c: In function `XvMCGetSubpictureStatus':
> I810XvMC.c:4283: error: `privSubpicture' undeclared (first use in this
> function)
> I810XvMC.c:4284: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:4293: error: parse error before ')' token
> I810XvMC.c:4295: error: parse error before ')' token
> I810XvMC.c: In function `XvMCQueryAttributes':
> I810XvMC.c:4343: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c:4344: warning: ISO C89 forbids mixed declarations and code
> I810XvMC.c: In function `XvMCSetAttribute':
> I810XvMC.c:4399: error: `pI810XvMC' undeclared (first use in this
> function)
> I810XvMC.c: In function `XvMCGetAttribute':
> I810XvMC.c:4470: error: `pI810XvMC' undeclared (first use in this
> function)
> make[5]: *** [I810XvMC.o] Error 1
> make[5]: Leaving directory
> `/home/gismobile/projects/xorg/work2/xc/lib/XvMC/hw/i810'
> make[4]: *** [all] Error 2
> make[4]: Leaving directory
> `/home/gismobile/projects/xorg/work2/xc/lib/XvMC'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory `/home/gismobile/projects/xorg/work2/xc/lib'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/home/gismobile/projects/xorg/work2/xc'
> make[1]: *** [World] Error 2
> make[1]: Leaving directory `/home/gismobile/projects/xorg/work2/xc'
> make: *** [World] Error 2
> -- snip --
>
> ;-(
>
> ----
>
> Bye,
> Roland
>
> P.S.: It seems that a workaround is to place |#define BuildXvExt NO|
> in xc/config/cf/host.def
>
> --
> __ . . __
> (o.\ \/ /.o) [email protected]
> \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
> /O /==\ O\ TEL +49 641 7950090
> (;O/ \/ \O;)
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From braun at club-internet.fr Wed Jun 16 12:59:12 2004
From: braun at club-internet.fr (Damien Ciabrini)
Date: Wed Jun 16 12:59:13 2004
Subject: [Xorg] kdrive compilation fails
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Hello Cameron,
On Wednesday 16 June 2004 21:02, Cameron wrote:
> I get this following error:
>
> mgadraw.c:29:25: g400_common.h: No such file or directory
> mgadraw.c: In function `mgaDrawInit':
> mgadraw.c:255: error: `mgaPrepareBlend' undeclared (first use in this
> function)
> mgadraw.c:255: error: (Each undeclared identifier is reported only once
> mgadraw.c:255: error: for each function it appears in.)
> mgadraw.c:256: error: `mgaBlend' undeclared (first use in this function)
> mgadraw.c:257: error: `mgaDoneBlend' undeclared (first use in this
> function) mgadraw.c:258: error: `mgaPrepareComposite' undeclared (first use
> in this function)
> mgadraw.c:259: error: `mgaComposite' undeclared (first use in this
> function) mgadraw.c:260: error: `mgaDoneComposite' undeclared (first use in
> this function)
> mgadraw.c: At top level:
> mgadraw.c:228: warning: `mgaUploadToScreen' defined but not used
> make[3]: *** [mgadraw.o] Error 1
> make[3]: Leaving directory `/usr/src/xserver/xserver/hw/kdrive/mga'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/src/xserver/xserver/hw/kdrive'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/src/xserver/xserver/hw'
> make: *** [all-recursive] Error 1
>
> I did a locate g400_common.h, it is not found on my system at all. So maybe
> someone forgot to submit that file. :)
>
> -Cameron
I'm very sorry for the inconvenient. Pleas find it attached in this mail
(until a real CVS commit fix the pb)
If another file is missing, please apply the patch I sent to the ML a few days
ago... Thanks for your patience.
--
Damien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g400_common.h
Type: text/x-chdr
Size: 8159 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040616/f1fb401b/g400_c
ommon-0001.h
From braun at club-internet.fr Wed Jun 16 14:42:13 2004
From: braun at club-internet.fr (Damien Ciabrini)
Date: Wed Jun 16 14:42:09 2004
Subject: [Xorg] kdrive compilation fails
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Wednesday 16 June 2004 21:59, Damien Ciabrini wrote:
> I'm very sorry for the inconvenient. Pleas find it attached in this mail
> (until a real CVS commit fix the pb)
>
> If another file is missing, please apply the patch I sent to the ML a few
> days ago... Thanks for your patience.
>
It should be fixed in the CVS now.
--
Damien
From hiryu at audioseek.net Wed Jun 16 15:26:53 2004
From: hiryu at audioseek.net (Cameron)
Date: Wed Jun 16 15:14:39 2004
Subject: [Xorg] kdrive compilation fails
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Seems to build now. There was at least one other file missing but I figured
I'd let you update CVS first.
Thanks!
-Cameron
On Wednesday 16 June 2004 2:42 pm, Damien Ciabrini wrote:
> On Wednesday 16 June 2004 21:59, Damien Ciabrini wrote:
> > I'm very sorry for the inconvenient. Pleas find it attached in this mail
> > (until a real CVS commit fix the pb)
> >
> > If another file is missing, please apply the patch I sent to the ML a few
> > days ago... Thanks for your patience.
>
> It should be fixed in the CVS now.
>
> --
> Damien
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From eta at lclark.edu Wed Jun 16 15:42:13 2004
From: eta at lclark.edu (Eric Anholt)
Date: Wed Jun 16 15:42:47 2004
Subject: [Xorg] Xfbdev acceleration.
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <1087425732.973.5.camel@leguin>
On Wed, 2004-06-16 at 08:06, Michael Frey wrote:
> Hello,
>
>
> I have been using Xfbdev from the XFree86 branch for some time. I
> added acceleration code to fbdev for an Epson chip I am using. It
> works great.
> I want to move to the freedesktop.org Xfbdev server and I am having
> trouble moving my blt code over. I noticed that the new server uses
> offscreen pixmaps for acceleration.
>
> My video card does not have enough memory for offscreen pixmaps and
> only has enough memory for the on-screen frame buffer. If I fill out
> in fbinit.c my functions for acceleration they never get called because
> in fbdev.c
> screen->memory_size = 0;
> screen->off_screen_base = 0;
>
> I tried changing the memory setting to be the memory size of my board
> but with no luck.
>
> Is there a way to enable acceleration without using offscreen pixmaps
> the way the old kdrive used to do it?
To add acceleration for a card, you shouldn't have to touch the
hw/kdrive/fbdev/*. Add your code to a new driver, and use the fbdev
functions to do the mode setting for you. You can see an example of
this, but with the vesa vs fbdev backend changeable, in the Xati driver
or several others in the tree.
The KAA_OFFSCREEN_PIXMAPS flag is what controls whether offscreen
pixmaps are used or not.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From carl at personnelware.com Wed Jun 16 17:56:39 2004
From: carl at personnelware.com (Carl Karsten)
Date: Wed Jun 16 17:52:53 2004
Subject: [Xorg] HEADSUP: DRI merged
References: <1087382601.94770.14.camel@leguin> <[email protected]>
<1087413514.859.63.camel@leguin>
Message-ID: <200101c45405$f3c4ff00$1e01a8c0@cnt496>
> > I810XvMC.c: In function `XvMCGetAttribute':
> > I810XvMC.c:4470: error: `pI810XvMC' undeclared (first use in this
>
> Should be fixed now. Thanks!
yup - all compiled!
Carl K
From asterius at airpost.net Wed Jun 16 18:10:03 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Wed Jun 16 18:10:43 2004
Subject: [Xorg] Successfully compiled Kdrive, but...
Message-ID: <[email protected]>
I think I'll try again. What Firefox and other GUI Wms and apps Kdrive
dependencies needed in order to compile? How do I start ratpoison or
firefox with Kdrive on a command line? I appreciate any hints on topic.
Asterius.
[email protected]> said:
>
> Do you have a ps/2 mouse? try 'modprobe psmouse'. usb mouse?
> try adding -mouse /dev/input/mice to your c ommand line.
>
> -- jaym
>
>
> Tue, Jun 15, 2004 at 06:22:16PM -0800, Asterius Pandoras wrote:
> > Hi everyone. Some readers might know my troubles compiling Kdrive
> > with ebuild that Gentoo provides ( and I am not alone). My mouse wasn't
> > working. Painstakingly searching the web and asking questions on this
> > mailing list didn't glean any hints except finding out that one person
> > successfully compiled Kdrive defining host.def file against sources
> > after failing to compile with Gentoo ebuild ( shame on you Gentoo
> > developers). I have followed his way and vaola, my Xvesa and Xfbdev are
> > working. I've build it defining #ProjectRoot /usr/X11R6 while my working
> > directory was /home/kdrive/xc asuming that all files needed will be
> > installed in this directory. However I didn't find there any. Then,
> > I have just copied and tested both servers and as I said they work as
> > standalone. My qestion is this. While they can work on their own, isn't
> > it correct that I need shared libraries in /usr/X11R6, includes etc. in
> > there in order to compile other X apps like mozilla for instance?
> > Probably I had to " make install " after " make World"? What files(
> > or directory do I have to copy in my /usr/X11R6 ? Thanks in advance.
> >
> > Asterius.
> >
> > _______________________________________________
> > xorg mailing list
> > [email protected]
> > http://freedesktop.org/mailman/listinfo/xorg
>
> --
> --
> Jaymz Julian - Coder, Visionary, Fat Ass.
> "Hannibal is a serial killer. He only likes to kill and eat people.
> Very few people have `I want to be killed and eaten' on their cards,
> so Hannibal is out of a job." - http://cards.sf.net
From daniel at freedesktop.org Wed Jun 16 20:15:08 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Wed Jun 16 20:15:08 2004
Subject: [Xorg] New commiter process?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Wed, Jun 16, 2004 at 05:11:40PM +0000, Charles Goodwin wrote:
> I hope you don't mind, but I'd like to interject in order to do a bit of
> software evangelizing as it answers the problem of having to trust new
> committers.
>
> CVS is bad. It really is. And you can't appreciate how bad it is until
> you use something better. And with a project like XServer where there
> are different groups with different interests, there is nothing better
> than distributed SCM [Source Code Management].
>
> Two alternatives are monotone [1] and GNU Arch [2], but the SCM tool I'm
> going to focus on is the one we [3] use, Darcs [4].
>
> [...]
I think Arch is sensational, and I'd personally love to see X using it,
and am happy to help effect that change. But the reality is that we're
using CVS, and will be for a while now, so we're after stuff to help
ease the pain of CVS.
Sorry to disappoint you, but we're not switching RCSs quite so soon.
--
Daniel Stone <[email protected]>
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/20040617/b6cb2dbb/attach
ment.pgp
From daniel at freedesktop.org Wed Jun 16 20:17:39 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Wed Jun 16 20:17:39 2004
Subject: [Xorg] New commiter process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Wed, Jun 16, 2004 at 05:42:24PM +0000, Charles Goodwin wrote:
> On Wed, 2004-06-16 at 13:14 -0400, Sean Middleditch wrote:
> > Xorg isn't switching anytime soon though for purely logistic reasons,
>
> The rebuttal to that would be that a distributed SCM tool is better
> "logistically" than CVS, but sheesh some say Emacs is better than Vi.
The problem is that tools to do these conversions are just not quite
there yet and, well:
640M /cvs/xorg
Right now everyone knows CVS and can work with it. Getting everyone who
uses X over to arch (which involves switching the X.Org, fd.o
xlibs/xapps/xserver, DRI and possibly XFree86 repositories) is a *lot*
of work, and something that needs to be planned a long time before it
happens, involve everyone, and have a couple of people dedicated to the
task.
We fail on the last point alone (I don't have the time, and I don't
think anyone else does).
--
Daniel Stone <[email protected]>
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/20040617/3f4e00fa/attach
ment.pgp
From jonsmirl at yahoo.com Wed Jun 16 20:55:03 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Wed Jun 16 20:55:06 2004
Subject: [Xorg] New commiter process?
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I know we're not going to switch but I'll put in my monthly plug for
Bitkeeper since I use it to work on the kernel. Bitkeeper has a two way
real-time CVS bridge that tracks everything. This lets kernel
developers who refuse to use Bitkeeper continue using CVS. The kernel
source is available via the bridge in CVS format so there is no data
lock-in with Bitkeeper file formats. Larry is also working on a scheme
for securely tracking who contributed what to a source tree (to address
future SCO's).
I do believe a peer based version control system is way, way, way
better than CVS. Using one would probably eliminate a lot of the
arguments we have.
--- Daniel Stone <[email protected]> wrote:
> On Wed, Jun 16, 2004 at 05:42:24PM +0000, Charles Goodwin wrote:
> > On Wed, 2004-06-16 at 13:14 -0400, Sean Middleditch wrote:
> > > Xorg isn't switching anytime soon though for purely logistic
> reasons,
> >
> > The rebuttal to that would be that a distributed SCM tool is better
> > "logistically" than CVS, but sheesh some say Emacs is better than
> Vi.
>
> The problem is that tools to do these conversions are just not quite
> there yet and, well:
> 640M /cvs/xorg
>
> Right now everyone knows CVS and can work with it. Getting everyone
> who
> uses X over to arch (which involves switching the X.Org, fd.o
> xlibs/xapps/xserver, DRI and possibly XFree86 repositories) is a
> *lot*
> of work, and something that needs to be planned a long time before it
> happens, involve everyone, and have a couple of people dedicated to
> the
> task.
>
> We fail on the last point alone (I don't have the time, and I don't
> think anyone else does).
>
> --
> Daniel Stone
> <[email protected]>
> freedesktop.org: powering your desktop
> http://www.freedesktop.org
>
> ATTACHMENT part 1.2 application/pgp-signature name=signature.asc
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
From daniel at freedesktop.org Wed Jun 16 21:26:54 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Wed Jun 16 21:26:54 2004
Subject: [Xorg] New commiter process?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Wed, Jun 16, 2004 at 08:55:03PM -0700, Jon Smirl wrote:
> I know we're not going to switch but I'll put in my monthly plug for
> Bitkeeper since I use it to work on the kernel. Bitkeeper has a two way
> real-time CVS bridge that tracks everything. This lets kernel
> developers who refuse to use Bitkeeper continue using CVS. The kernel
> source is available via the bridge in CVS format so there is no data
> lock-in with Bitkeeper file formats. Larry is also working on a scheme
> for securely tracking who contributed what to a source tree (to address
> future SCO's).
GNU arch also has a bidirectional (or unidirectional, if you prefer) CVS
gateway, and supports changeset signing.
--
Daniel Stone <[email protected]>
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/20040617/69fbca63/attach
ment.pgp
From dev.macs at freemail.hu Wed Jun 16 23:25:32 2004
From: dev.macs at freemail.hu (Dev.Macs)
Date: Wed Jun 16 23:26:53 2004
Subject: [Xorg] migrating via epia's trident driver is needed
Message-ID: <[email protected]>
Dear All,
I have an epia 800 mini-itx board.
I use the gentoo + Xorg 6.7.0 on it.
I would liket to use it with television, but it requires a trident
driver, which is downloadable from via.
In fact, that driver wroted for xfree86 and I can't compile the
sourcecode under xorg.
I modified the makefile (to correct the paths), but many of header
files missing from xorg.
Can anybody migrate the sourcecode from xfree to xorg? I don't want to
downgrade the X from xorg to xfree.
Of course, I can send the sourcecode or link, where it downloadable.
http://downloads.viaarena.com/drivers/video/KPLE/via_kple_v1.2.1_20040127.tgz
--
Best regards,
Dev.Macs mailto:[email protected]
From julius at solutions-i.org Thu Jun 17 07:38:43 2004
From: julius at solutions-i.org (P.I.Julius)
Date: Thu Jun 17 00:37:38 2004
Subject: [Xorg] Xvesa, Xfbdev, Xchips ... wrong colors?
Message-ID: <1087483123.2462.9.camel@julius>
Hi,
Sorry for bothering again, but i still have this problem:
http://julius.solutions-i.org/uploaded/images/xvesa.jpg
I have downloaded the latest cvs yesterday, but nothings happen.
I have tried out the -swaprgb option too, but i have the same problem.
This is only happening at 16 bit, if i use 24 everything is fine.
I have an NVidia gForce 4, i use Fedora Core 2, i have tried out Xvesa,
Xfbdev too but the same result.
If You need more info please write me how can i get it and i will send
it to You.
Please help!
Thanks in Advance,
Julius
From eta at lclark.edu Thu Jun 17 03:00:15 2004
From: eta at lclark.edu (Eric Anholt)
Date: Thu Jun 17 03:00:50 2004
Subject: [Xorg] R100/R200 render acceleration
Message-ID: <1087466415.7506.6.camel@leguin>
http://freedesktop.org/bugzilla/show_bug.cgi?id=748
Attached to that bug is a patch for Render acceleration on R100 and
R200. I'm running the R200 stuff on my desktop, and R100 seems just as
good in the little testing I've done. I'd appreciate if adventurous
folks could try the patch and report any issues in that bug, so we don't
get any surprises when it's committed. Note that it's only enabled when
the DRI is working.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From carl at personnelware.com Thu Jun 17 03:25:10 2004
From: carl at personnelware.com (Carl Karsten)
Date: Thu Jun 17 03:20:28 2004
Subject: [Xorg] (EE) I810: Failed to load module "dri"
References: <1087382601.94770.14.camel@leguin>
<[email protected]><1087413514.859.63.camel@leguin>
<200101c45405$f3c4ff00$1e01a8c0@cnt496>
Message-ID: <21cd01c45455$5f4112b0$1e01a8c0@cnt496>
Is this something I should worry about?
(EE) I810: Failed to load module "dri" (once-only module, 0)
I got that line before, so it was not caused by the DRI merge. I was hoping it
would magicaly go away, no such luck ;)
I do see
(II) I810(0): [DRI] installation complete
So im not sure what the EE line is about.
Below is my log.
Carl K
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/LinuxBook1:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Release Date: 18 December 2003
X Protocol Version 11, Revision 0, Release 6.7
Build Operating System: Linux 2.6.7-rc3-bk5 i686 [ELF]
Current Operating System: Linux LinuxBook1 2.6.7-rc3-bk5 #1 Mon Jun 14 18:16:03
GMT 2004 i686
Build Date: 16 June 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: Wed Jun 16 20:34:50 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"
compiled for 6.7.0, module version = 1.0.0
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:01:0: chip 8086,7121 card 8086,7121 rev 02 class 03,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:1: chip 8086,2421 card 0000,0000 rev 01 class 01,01,80 hdr 00
(II) PCI: 00:1f:2: chip 8086,2422 card 0000,0000 rev 01 class 0c,03,00 hdr 00
(II) PCI: 01:04:0: chip 1282,9102 card 0291,8212 rev 10 class 02,00,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)
(II) Bus 1 I/O range:
[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]
(II) Bus 1 non-prefetchable memory range:
[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)
[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) OS-reported resource ranges after removing overlaps with PCI:
[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) All system 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 0xd5000000 - 0xd500007f (0x80) MX[B]
[6] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) 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"
compiled for 6.7.0, module version = 1.13.0
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"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(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 XFree86-DGA
(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"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "dri"
(II) Loading /usr/X11R6/lib/modules/extensions/libdri.a
(II) Module dri: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "drm"
(II) LoadModule: "drm"
(II) Loading /usr/X11R6/lib/modules/linux/libdrm.a
(II) Module drm: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension XFree86-DRI
(II) LoadModule: "glx"
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.a
(II) Module glx: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading sub module "GLcore"
(II) LoadModule: "GLcore"
(II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a
(II) Module GLcore: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension GLX
(II) LoadModule: "xtrap"
(II) Loading /usr/X11R6/lib/modules/extensions/libxtrap.a
(II) Module xtrap: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.2
(II) Loading extension DEC-XTRAP
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.2
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(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"
compiled for 6.7.0, module version = 1.0.1
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.4
(II) Loading font Speedo
(II) LoadModule: "i810"
(II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o
(II) Module i810: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.3.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 0.7
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
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
(II) Primary Device is: PCI 00:01:0
(--) Chipset i810 found
(II) resource ranges after xf86ClaimFixedResources() call:
[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 0xd5000000 - 0xd500007f (0x80) MX[B]
[6] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) 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:
[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 0xd5000000 - 0xd500007f (0x80) MX[B]
[6] -1 0 0xd6000000 - 0xd607ffff (0x80000) MX[B](B)
[7] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) 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"
compiled for 6.7.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 0.7
(**) 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"
compiled for 6.7.0, module version = 1.1.0
ABI class: X.Org Video Driver, version 0.7
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Loading /usr/X11R6/lib/modules/linux/libint10.a
(II) Module int10: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Video Driver, version 0.7
(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"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org Video Driver, version 0.7
(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: CPQ Model: f46 Serial#: 1781805617
(II) I810(0): Year: 1996 Week: 12
(II) I810(0): EDID Version: 1.0
(II) I810(0): Analog Display Input, Input Voltage Level: 0.700/0.300 V
(II) I810(0): Sync: Separate
(II) I810(0): Max H-Image Size [cm]: horiz.: 27 vert.: 20
(II) I810(0): Gamma: 1.07
(II) I810(0): DPMS capabilities: StandBy; RGB/Color Display
(II) I810(0): redX: 0.620 redY: 0.350 greenX: 0.305 greenY: 0.600
(II) I810(0): blueX: 0.155 blueY: 0.065 whiteX: 0.281 whiteY: 0.311
(II) I810(0): Supported VESA Video Modes:
(II) I810(0): 720x400@70Hz
(II) I810(0): 640x480@60Hz
(II) I810(0): 640x480@75Hz
(II) I810(0): 800x600@60Hz
(II) I810(0): 800x600@75Hz
(II) I810(0): 1024x768@60Hz
(II) I810(0): Manufacturer's mask: 0
(--) 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 "640x400" (vrefresh out of range)
(II) I810(0): Not using default mode "320x200" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "720x400" (vrefresh out of range)
(II) I810(0): Not using default mode "360x200" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "640x480" (vrefresh out of range)
(II) I810(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "640x480" (vrefresh out of range)
(II) I810(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "640x480" (vrefresh out of range)
(II) I810(0): Not using default mode "320x240" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (vrefresh out of range)
(II) I810(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (vrefresh out of range)
(II) I810(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (vrefresh out of range)
(II) I810(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (hsync out of range)
(II) I810(0): Not using default mode "400x300" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (unknown reason)
(II) I810(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (hsync out of range)
(II) I810(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (hsync out of range)
(II) I810(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (hsync out of range)
(II) I810(0): Not using default mode "512x384" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1152x864" (hsync out of range)
(II) I810(0): Not using default mode "576x432" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1280x960" (hsync out of range)
(II) I810(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1280x960" (hsync out of range)
(II) I810(0): Not using default mode "640x480" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1280x1024" (hsync out of range)
(II) I810(0): Not using default mode "640x512" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1280x1024" (hsync out of range)
(II) I810(0): Not using default mode "640x512" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1280x1024" (hsync out of range)
(II) I810(0): Not using default mode "640x512" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1600x1200" (hsync out of range)
(II) I810(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1600x1200" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "800x600" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1792x1344" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "896x672" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1792x1344" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "896x672" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1856x1392" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "928x696" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1856x1392" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "928x696" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1920x1440" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1920x1440" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "832x624" (vrefresh out of range)
(II) I810(0): Not using default mode "416x312" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1152x768" (vrefresh out of range)
(II) I810(0): Not using default mode "576x384" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1400x1050" (hsync out of range)
(II) I810(0): Not using default mode "700x525" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1400x1050" (hsync out of range)
(II) I810(0): Not using default mode "700x525" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1600x1024" (hsync out of range)
(II) I810(0): Not using default mode "800x512" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1920x1440" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "960x720" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "2048x1536" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "2048x1536" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "2048x1536" (bad mode
clock/interlace/doublescan)
(II) I810(0): Not using default mode "1024x768" (bad mode
clock/interlace/doublescan)
(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): Display dimensions: (270, 200) mm
(--) I810(0): DPI set to (75, 76)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/X11R6/lib/modules/libfb.a
(II) Module fb: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
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"
compiled for 6.7.0, module version = 1.1.0
ABI class: X.Org Video Driver, version 0.7
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Loading /usr/X11R6/lib/modules/libramdac.a
(II) Module ramdac: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 0.7
(II) Loading sub module "shadowfb"
(II) LoadModule: "shadowfb"
(II) Loading /usr/X11R6/lib/modules/libshadowfb.a
(II) Module shadowfb: vendor="X.Org Foundation"
compiled for 6.7.0, module version = 1.0.0
ABI class: X.Org ANSI C Emulation, version 0.2
(**) I810(0): page flipping disabled
(**) I810(0): 6 XvMC Surfaces Requested.
(II) Loading sub module "dri"
(II) LoadModule: "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]
[2] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B)
[3] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(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)
[9] -1 0 0xd0000000 - 0xd3ffffff (0x4000000) 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)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:01.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
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): Adding 768 scanlines for pixmap caching
(II) I810(0): Allocated Scratch Memory
(II) I810(0): [dri] Buffer map : 49f000
(II) I810(0): [drm] added 256 4096 byte DMA buffers
(II) I810(0): [drm] Init v1.4 interface.
(II) I810(0): [drm] dma control initialized, using IRQ -1007
(II) I810(0): [dri] visual configs initialized.
(==) I810(0): Write-combining range (0xd0000000,0x4000000)
(II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) I810(0): Setting dot clock to 40.0 MHz [ 0x8 0x1 0x30 ] [ 10 3 3 ]
(II) I810(0): chose watermark 0x22007000: (tab.freq 40.0)
(II) I810(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 Horizontal and Vertical Lines
Offscreen Pixmaps
Setting up tile and stipple cache:
28 128x128 slots
6 256x256 slots
(==) I810(0): Backing store disabled
(==) I810(0): Silken mouse enabled
(II) I810(0): X context handle = 0x00000001
(II) I810(0): [drm] installed DRM signal handler
(II) I810(0): [DRI] installation complete
(==) I810(0): Direct rendering enabled
(==) RandR enabled
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension LBX
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(**) Option "Protocol" "IMPS/2"
(**) Mouse0: Device: "/dev/psaux"
(**) Mouse0: Protocol: "IMPS/2"
(**) Option "CorePointer"
(**) Mouse0: Core Pointer
(**) Option "Device" "/dev/psaux"
(==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50
(**) Option "ZAxisMapping" "4 5"
(**) Mouse0: ZAxisMapping: buttons 4 and 5
(**) Mouse0: Buttons: 5
(II) Keyboard "Keyboard0" handled by legacy driver
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(II) Mouse0: ps2EnableDataReporting: succeeded
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xd4a90000 at 0x401d6000
From thomas at winischhofer.net Thu Jun 17 03:43:06 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Thu Jun 17 03:45:11 2004
Subject: [Xorg] DRI merge - SiS DDX driver
Message-ID: <[email protected]>
The merge of the DRI as of 20040613 resurrected some files in the SiS
(DDX) driver directory which have been rightfully dead for a long time:
sis530_accel.*
sis_bios.*
Please delete them again.
BTW: What's xf86drmSiS.h doing there? Isn't that supposed to be
somewhere else?
Thanks,
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
From thomas at winischhofer.net Thu Jun 17 05:04:02 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Thu Jun 17 05:06:14 2004
Subject: [Xorg] Introduce DRI_VERSION?
Message-ID: <[email protected]>
Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the
same style as XORG_VERSION_CURRENT so that changes like the types from
drmHandle -> drm_handle_t can be handled smoothly with the C
preprocessor for older versions?
Point being: I would like to compile my DDX driver with both XFree86 and
X.org as I don't have time to maintain two or more versions. Since the
preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT
would come extremely handy.
That shouldn't cause too much hassle...
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
From stratos at zeelandnet.nl Thu Jun 17 05:38:20 2004
From: stratos at zeelandnet.nl ([email protected])
Date: Thu Jun 17 05:38:52 2004
Subject: [Xorg] xserver undefined symbol: BuiltinRegisterFpefunctions
Message-ID: <[email protected]>
I've compiled xserver with the compiling script, but when i want to launch
one of the servers he switches the screen and then simply hangs.
keyboard and mouse input simply do not work. CTRL+ALT+backspace doesnt do
a thing.
(although when i login remote and start up another X server the screen
will go to that one and evrything is alright again.)
when i start up Xfake it gives the following error.
./Xfake: relocation error: ./Xfake: undefined symbol:
BuiltinRegisterFpeFunctions
when googling on that i found this thread
http://freedesktop.org/pipermail/xserver/2004-May/001387.html
his problem matches mine to the letter, but since no answer was born out
of that thread, very helpfull it was not.
does anyone know a answer to this? i used to be able to use the xserver
but that was now months ago.
From alexdeucher at gmail.com Thu Jun 17 05:58:10 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Thu Jun 17 05:58:17 2004
Subject: [Xorg] migrating via epia's trident driver is needed
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Thu, 17 Jun 2004 08:25:32 +0200, Dev.Macs <[email protected]> wrote:
>
> Dear All,
>
> I have an epia 800 mini-itx board.
> I use the gentoo + Xorg 6.7.0 on it.
>
> I would liket to use it with television, but it requires a trident
> driver, which is downloadable from via.
>
> In fact, that driver wroted for xfree86 and I can't compile the
> sourcecode under xorg.
> I modified the makefile (to correct the paths), but many of header
> files missing from xorg.
>
> Can anybody migrate the sourcecode from xfree to xorg? I don't want to
> downgrade the X from xorg to xfree.
Could you create a diff of the changes? the trident driver in cvs
should be pretty close the the via one. theirs is based on the
xfree86 driver. you could probably even apply the diff to your xorg
tree.
Alex
>
> Of course, I can send the sourcecode or link, where it downloadable.
> http://downloads.viaarena.com/drivers/video/KPLE/via_kple_v1.2.1_20040127.tgz
>
> --
> Best regards,
> Dev.Macs mailto:[email protected]
>
From alexdeucher at gmail.com Thu Jun 17 06:01:21 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Thu Jun 17 06:01:27 2004
Subject: [Xorg] R100/R200 render acceleration
In-Reply-To: <1087466415.7506.6.camel@leguin>
References: <1087466415.7506.6.camel@leguin>
Message-ID: <[email protected]>
On Thu, 17 Jun 2004 03:00:15 -0700, Eric Anholt <[email protected]> wrote:
>
> http://freedesktop.org/bugzilla/show_bug.cgi?id=748
>
> Attached to that bug is a patch for Render acceleration on R100 and
> R200. I'm running the R200 stuff on my desktop, and R100 seems just as
> good in the little testing I've done. I'd appreciate if adventurous
> folks could try the patch and report any issues in that bug, so we don't
> get any surprises when it's committed. Note that it's only enabled when
> the DRI is working.
Just curious, was there a problem with the MMIO code paths for render
accel? ati's original drop supported both CP and MMIO accel so it
would work even when the dri was disabled. Admittedly, I haven't
gotten a chance to test either patch yet.
Alex
>
> --
> Eric Anholt [email protected]
> http://people.freebsd.org/~anholt/ [email protected]
>
From jens at tungstengraphics.com Thu Jun 17 08:09:03 2004
From: jens at tungstengraphics.com (Jens Owen)
Date: Thu Jun 17 08:04:19 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Thomas Winischhofer wrote:
>
> Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in the
> same style as XORG_VERSION_CURRENT so that changes like the types from
> drmHandle -> drm_handle_t can be handled smoothly with the C
> preprocessor for older versions?
>
> Point being: I would like to compile my DDX driver with both XFree86 and
> X.org as I don't have time to maintain two or more versions. Since the
> preprocessor can't check for typedefs (AFAIK...) a DRI_VERSION_CURRENT
> would come extremely handy.
>
> That shouldn't cause too much hassle...
Thomas,
Versioning has always been a tricky issue for DRI developers, and
consequently keeping version numbering simple and up to date is important.
I'd encourage you to considering using/enhancing the existing DRI and
DRM versioning. For example, I'm wondering if the runtime version
already built into DRM would help. It could be extended to use compile
time #define's in places where we currently hard code constants, for
example in drmGetLibVersion it looks like the minor version was just
bumped to 2. The source for the linux version of this example be seen at:
xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c
--
/\
Jens Owen / \/\ _
[email protected] / \ \ \ Steamboat Springs, Colorado
From carl at personnelware.com Thu Jun 17 08:48:14 2004
From: carl at personnelware.com (Carl Karsten)
Date: Thu Jun 17 08:43:31 2004
Subject: [Xorg] startx failes if no path
Message-ID: <241001c45482$80c9b180$1e01a8c0@cnt496>
Basically I am trying to run startx without a path and get:
/usr/X11R6/bin/startx: line 132: xauth: command not found
$ which xauth
/usr/X11R6/bin/xauth
If that is expected, then I'll set a path. If that is not expected, then I'll
file a bug report.
Details: I am trying to run startx with irexec which gets run from local.start.
/etc/conf.d/local.start:
su - carl -c '/usr/bin/screen -d -m /usr/bin/irexec'
/home/carl/.lircrc:
begin irexec
begin
remote = CREATIVE_INFRA_DVD
button = play
prog=irexec
# config=/usr/bin/mplayer dvd://1
# config=DISPLAY=:0 mplayer /mnt/auto/cdrom/*
config=/usr/X11R6/bin/startx -e mplayer /mnt/auto/cdrom/*
end
With some experimenting, I did get it to work:
config=PATH=/usr/X11R6/bin:/bin:/usr/bin startx -e /usr/local/bin/mplayer
/mnt/auto/cdrom/*
If you followed it this far, maybe you can answer a related question:
startx displays it's stuff to the screen session. mplayer opens 2 X windows: 1
for the movie, one for it's console output. I would like the console output to
go to the screen session.
I am guessing the 2nd window with mplayer status is taking up a few extra cpu
cycles and Celeron 600 can barely play as it is.
http://www.personnelware.com/carl/resume.html
From thomas at winischhofer.net Thu Jun 17 09:47:18 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Thu Jun 17 09:49:23 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Jens Owen wrote:
> Thomas Winischhofer wrote:
>>
>> Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in
>> the same style as XORG_VERSION_CURRENT so that changes like the types
>> from drmHandle -> drm_handle_t can be handled smoothly with the C
>> preprocessor for older versions?
>>
>> Point being: I would like to compile my DDX driver with both XFree86
>> and X.org as I don't have time to maintain two or more versions. Since
>> the preprocessor can't check for typedefs (AFAIK...) a
>> DRI_VERSION_CURRENT would come extremely handy.
>>
>> That shouldn't cause too much hassle...
>
>
> Thomas,
>
> Versioning has always been a tricky issue for DRI developers, and
> consequently keeping version numbering simple and up to date is important.
>
> I'd encourage you to considering using/enhancing the existing DRI and
> DRM versioning. For example, I'm wondering if the runtime version
> already built into DRM would help. It could be extended to use compile
> time #define's in places where we currently hard code constants, for
> example in drmGetLibVersion it looks like the minor version was just
> bumped to 2. The source for the linux version of this example be seen at:
>
> xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c
>
Jens, thanks for your response.
Just to avoid a misunderstanding: This version definition is not meant
as an ABI/API/whatever number; I'd just need that for compilation reasons.
If it is complicated for the DRI folks, why not keep such a version
#definition in the x.org tree which is updated each time a merge from
the DRI tree happens?
For example, in xf86drm.h just add
#define DRI_DATE 20040616
That would solve my particular problem quite easily. The name of the
#define is entirely up to you... choose freely. The date format should
be in a form suitable for comparison.
That isn't too much work, is it?
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
From hiryu at audioseek.net Thu Jun 17 10:25:42 2004
From: hiryu at audioseek.net (Cameron)
Date: Thu Jun 17 10:13:30 2004
Subject: [Xorg] xserver undefined symbol: BuiltinRegisterFpefunctions
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
I have exactly the same trouble. What video card and kernel are you running?
I was wondering if it was 2.6 related because when it seemed to work before, I
was running 2.4. Though I haven't tried 2.4 again.
Here is the response I got:
"It probably has something to do with your VESA bios not responding
correctly when queried for modes. I have the same issue with an entirely
unrelated video card, and traced it down to the VESA mode enumeration
function. Since almost all of the KDrive drivers use VESA for
initialization on some level, a card with a slightly-different BIOS
than the VESA routines expect causes a hang.
I still don't have a fix though, mainly due to time constraints. Once, the
VESA routines worked after several sleep/wake cycles on a laptop, as if
some random register got set to the right value, but I couldn't reproduce
it.
? - Brent"
On Thursday 17 June 2004 5:38 am, [email protected] wrote:
> I've compiled xserver with the compiling script, but when i want to launch
> one of the servers he switches the screen and then simply hangs.
> keyboard and mouse input simply do not work. CTRL+ALT+backspace doesnt do
> a thing.
> (although when i login remote and start up another X server the screen
> will go to that one and evrything is alright again.)
>
> when i start up Xfake it gives the following error.
> ./Xfake: relocation error: ./Xfake: undefined symbol:
> BuiltinRegisterFpeFunctions
>
> when googling on that i found this thread
> http://freedesktop.org/pipermail/xserver/2004-May/001387.html
>
> his problem matches mine to the letter, but since no answer was born out
> of that thread, very helpfull it was not.
>
> does anyone know a answer to this? i used to be able to use the xserver
> but that was now months ago.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
--
"A dream to some... A NIGHTMARE TO OTHERS!"
From jens at tungstengraphics.com Thu Jun 17 10:26:25 2004
From: jens at tungstengraphics.com (Jens Owen)
Date: Thu Jun 17 10:21:39 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Thomas Winischhofer wrote:
> Jens Owen wrote:
>
>> Thomas Winischhofer wrote:
>>
>>>
>>> Would you DRI guys mind adding a #define for DRI_VERSION_CURRENT in
>>> the same style as XORG_VERSION_CURRENT so that changes like the types
>>> from drmHandle -> drm_handle_t can be handled smoothly with the C
>>> preprocessor for older versions?
>>>
>>> Point being: I would like to compile my DDX driver with both XFree86
>>> and X.org as I don't have time to maintain two or more versions.
>>> Since the preprocessor can't check for typedefs (AFAIK...) a
>>> DRI_VERSION_CURRENT would come extremely handy.
>>>
>>> That shouldn't cause too much hassle...
>>
>>
>>
>> Thomas,
>>
>> Versioning has always been a tricky issue for DRI developers, and
>> consequently keeping version numbering simple and up to date is
>> important.
>>
>> I'd encourage you to considering using/enhancing the existing DRI and
>> DRM versioning. For example, I'm wondering if the runtime version
>> already built into DRM would help. It could be extended to use
>> compile time #define's in places where we currently hard code
>> constants, for example in drmGetLibVersion it looks like the minor
>> version was just bumped to 2. The source for the linux version of
>> this example be seen at:
>>
>> xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c
>>
>
> Jens, thanks for your response.
>
> Just to avoid a misunderstanding: This version definition is not meant
> as an ABI/API/whatever number; I'd just need that for compilation reasons.
>
> If it is complicated for the DRI folks, why not keep such a version
> #definition in the x.org tree which is updated each time a merge from
> the DRI tree happens?
>
> For example, in xf86drm.h just add
>
> #define DRI_DATE 20040616
>
> That would solve my particular problem quite easily. The name of the
> #define is entirely up to you... choose freely. The date format should
> be in a form suitable for comparison.
>
> That isn't too much work, is it?
>
> Thomas
>
Thomas,
Adding the define is easy, what's difficult is cleaning up these little
hacks later without breaking binary compatability. As Keith W.
suggested earlier this week, there is a good chance the X portion of the
DRI development could end up in the X.org project. What would you set
the DRI_DATE string to then?
Perhaps it's time to bump the XORG_VERSION_CURRENT string to
differentiate between the last release of X.org and the next. Would
that help you?
--
/\
Jens Owen / \/\ _
[email protected] / \ \ \ Steamboat Springs, Colorado
From keithp at keithp.com Thu Jun 17 10:31:02 2004
From: keithp at keithp.com (Keith Packard)
Date: Thu Jun 17 10:31:25 2004
Subject: [Xorg] xserver undefined symbol: BuiltinRegisterFpefunctions
In-Reply-To: Your message of "Thu, 17 Jun 2004 14:38:20 +0200."
<[email protected]>
Message-ID: <[email protected]>
> ./Xfake: relocation error: ./Xfake: undefined symbol:
> BuiltinRegisterFpeFunctions
That function should be in libfont.so; it appears your library was built
without it for some reason.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040617/5ea223c6/attach
ment.pgp
From thomas at winischhofer.net Thu Jun 17 10:34:48 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Thu Jun 17 10:36:51 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Jens Owen wrote:
>>> Thomas,
>>>
>>> Versioning has always been a tricky issue for DRI developers, and
>>> consequently keeping version numbering simple and up to date is
>>> important.
>>>
>>> I'd encourage you to considering using/enhancing the existing DRI and
>>> DRM versioning. For example, I'm wondering if the runtime version
>>> already built into DRM would help. It could be extended to use
>>> compile time #define's in places where we currently hard code
>>> constants, for example in drmGetLibVersion it looks like the minor
>>> version was just bumped to 2. The source for the linux version of
>>> this example be seen at:
>>>
>>> xc/programs/Xserver/hw/xfree86/drivers/os-support/linux/drm/xf86drm.c
>>>
>>
>> Jens, thanks for your response.
>>
>> Just to avoid a misunderstanding: This version definition is not meant
>> as an ABI/API/whatever number; I'd just need that for compilation
>> reasons.
>>
>> If it is complicated for the DRI folks, why not keep such a version
>> #definition in the x.org tree which is updated each time a merge from
>> the DRI tree happens?
>>
>> For example, in xf86drm.h just add
>>
>> #define DRI_DATE 20040616
>>
>> That would solve my particular problem quite easily. The name of the
>> #define is entirely up to you... choose freely. The date format should
>> be in a form suitable for comparison.
>>
>> That isn't too much work, is it?
>>
>> Thomas
>>
>
> Thomas,
>
> Adding the define is easy, what's difficult is cleaning up these little
> hacks later without breaking binary compatability.
Again: What I suggest has nothing to do with binary compatibility. It is
just for compiling one and the same DDX code with different DRI
versions. However, I understand that this is something not many would
need. Perhaps I am just too kind to people stuck with Debian stable
(XFree86 4.1)...? ;)
> As Keith W.
> suggested earlier this week, there is a good chance the X portion of the
> DRI development could end up in the X.org project. What would you set
> the DRI_DATE string to then?
Erm.... got me, didn't consider that.
> Perhaps it's time to bump the XORG_VERSION_CURRENT string to
> differentiate between the last release of X.org and the next. Would
> that help you?
Yes, sure.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
From Alan.Coopersmith at Sun.COM Thu Jun 17 11:00:33 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Thu Jun 17 10:59:32 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Jens Owen wrote:
> Perhaps it's time to bump the XORG_VERSION_CURRENT string to
> differentiate between the last release of X.org and the next. Would
> that help you?
The big dri merge seems a good time to label snapshot 6.7.0.90 or
however we want to start identifying the pre-6.7.1 snapshots. (How
do we want to do that?)
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From KendallB at scitechsoft.com Thu Jun 17 11:35:24 2004
From: KendallB at scitechsoft.com (Kendall Bennett)
Date: Thu Jun 17 11:40:17 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: <[email protected]>
Message-ID: <40D181FC.19795.2CD055E8@localhost>
Hey Guys,
I have been quiet on these mailing lists for a while as we have been
slaving away on PowerPC support in our products. I am back working on our
X Server drivers again, and working on adding support for the X.org
servers. Part of our previous installer detects the installed XFree86
version to determine which module we should be installing. To do this we
look at the 'X -version' string and parse the XFree86 version number from
that.
Looking at the Xorg server output for the -version command it appears all
that changed was the first string that contained the XFree86 version
indentifier was removed, and the Release was upped to 6.7 from 6.6. I can
easily detect the initial X.org release by looking at the 6.7 string, but
I need to know if this version number is going to be revved for each
X.org official release.
Ie: will the next release from X.org be versioned as R6.8? If not, we
need to seriously considering putting some kind of release versioning
into the X server so third party driver installers like ours can detect
the server version correctly and install the correct driver modules based
on that information.
For now I will assume the 6.7 will change to 6.8, so I can get our
installer done. If that isn't the case we will need to fix it before the
next release ;-)
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
From asterius at airpost.net Thu Jun 17 15:27:34 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Thu Jun 17 15:27:37 2004
Subject: [Xorg] To start Xvesa with WM how?
Message-ID: <[email protected]>
Can anyone point me to code to start Xvesa ( or Xfbdev ) with Windows
Manager? Thanks.
Asterius.
From eta at lclark.edu Thu Jun 17 15:32:09 2004
From: eta at lclark.edu (Eric Anholt)
Date: Thu Jun 17 15:32:43 2004
Subject: [Xorg] R100/R200 render acceleration
In-Reply-To: <[email protected]>
References: <1087466415.7506.6.camel@leguin>
<[email protected]>
Message-ID: <1087511529.852.106.camel@leguin>
On Thu, 2004-06-17 at 06:01, Alex Deucher wrote:
> On Thu, 17 Jun 2004 03:00:15 -0700, Eric Anholt <[email protected]> wrote:
> >
> > http://freedesktop.org/bugzilla/show_bug.cgi?id=748
> >
> > Attached to that bug is a patch for Render acceleration on R100 and
> > R200. I'm running the R200 stuff on my desktop, and R100 seems just as
> > good in the little testing I've done. I'd appreciate if adventurous
> > folks could try the patch and report any issues in that bug, so we don't
> > get any surprises when it's committed. Note that it's only enabled when
> > the DRI is working.
>
> Just curious, was there a problem with the MMIO code paths for render
> accel? ati's original drop supported both CP and MMIO accel so it
> would work even when the dri was disabled. Admittedly, I haven't
> gotten a chance to test either patch yet.
ATI's original code drop, at least the version I got, didn't work. It
didn't compile out of the box, and the !AlphaTexture paths were
disabled. The vertex submission for the AlphaTexture appeared wrong --
a Z coord (I assume, it was 1.0f) was being included without accounting
for it in BEGIN_ACCEL() or RADEON_SE_VTX_FORMAT. My patch was based on
that patch originally, and you can see the MMIO vertex submission still
there for the !ACCEL_CP case that's disabled. I'd love to see the MMIO
version work, but it's not a high priority for me.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From roland.mainz at nrubsig.org Thu Jun 17 20:36:27 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Thu Jun 17 20:36:34 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test the Xorg
tree...
Message-ID: <[email protected]>
Hi!
----
Is there any interest here in convincing SourcForge to open their
compilefarm (read
http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
firewall (e.g. open the port for CVS that people can do checkouts from
pdx.freedesktop.org) that people can use those machines to build and
test Xorg/FreeDesktop projects ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From daniel at freedesktop.org Thu Jun 17 20:43:34 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Thu Jun 17 20:43:33 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test the
Xorg tree...
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Fri, Jun 18, 2004 at 05:36:27AM +0200, Roland Mainz wrote:
> Is there any interest here in convincing SourcForge to open their
> compilefarm (read
> http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
> firewall (e.g. open the port for CVS that people can do checkouts from
> pdx.freedesktop.org) that people can use those machines to build and
> test Xorg/FreeDesktop projects ?
Not really from here; we have a far better portability lab in Debian. We
get reasonable coverage of all the OSes from porters (*BSD, proprietary
Unices), and Debian covers 14 or 15 architectures or something (trust
me, it's a lot, and often architectures that upstream doesn't support,
such as S/390, ARM/Linux, et al). Between those two factors, we cover
most everything pretty nicely, and we don't have to involve SourceForge.
--
Daniel Stone <[email protected]>
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/20040618/cdd09f57/attach
ment.pgp
From jonsmirl at yahoo.com Thu Jun 17 20:52:30 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Thu Jun 17 20:52:38 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
Message-ID: <[email protected]>
Tinderbox and bonsai are two development tools used in Mozilla. They
would also be useful for Xorg. Anyone ambitious enough to set them up?
Tinderbox is a good tool for automatically making sure a minimal amount
of regression testing occurs for every automated build. Tinderbox is an
integral part of the Mozilla development process.
http://www.mozilla.org/projects/tinderbox/
http://www.mozilla.org/tinderbox.html
Sample status page:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
most of the numbers are automatic performance/size measurements. You
can get graphs of trends over time.
Bonsai is another good tool. It works like google for the source code
and lets you make fast queries on it. It automatically updates the
indices for check-ins.
http://www.mozilla.org/projects/bonsai/
And everyone knows about Bugzilla
http://www.mozilla.org/projects/bugzilla/
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
From daniel at freedesktop.org Thu Jun 17 20:54:03 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Thu Jun 17 20:54:03 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Thu, Jun 17, 2004 at 08:52:30PM -0700, Jon Smirl wrote:
> Tinderbox and bonsai are two development tools used in Mozilla. They
> would also be useful for Xorg. Anyone ambitious enough to set them up?
>
> Tinderbox is a good tool for automatically making sure a minimal amount
> of regression testing occurs for every automated build. Tinderbox is an
> integral part of the Mozilla development process.
>
> http://www.mozilla.org/projects/tinderbox/
> http://www.mozilla.org/tinderbox.html
>
> Sample status page:
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
> most of the numbers are automatic performance/size measurements. You
> can get graphs of trends over time.
>
>
> Bonsai is another good tool. It works like google for the source code
> and lets you make fast queries on it. It automatically updates the
> indices for check-ins.
>
> http://www.mozilla.org/projects/bonsai/
>
> And everyone knows about Bugzilla
> http://www.mozilla.org/projects/bugzilla/
Um, we already have both of these tools deployed on fd.o to build the
Xorg tree; Jim set them up a few months ago, in the early days.
--
Daniel Stone <[email protected]>
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/20040618/164d6863/attach
ment.pgp
From jonsmirl at yahoo.com Thu Jun 17 21:04:39 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Thu Jun 17 21:04:41 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Daniel Stone <[email protected]> wrote:
> Um, we already have both of these tools deployed on fd.o to build the
> Xorg tree; Jim set them up a few months ago, in the early days.
Where are the web pages for tinderbox and bonsai? I've been working on
xserver so I haven't tracked xorg. I just looked on fd.o and x.org and
can't find them.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
From daniel at freedesktop.org Thu Jun 17 21:20:27 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Thu Jun 17 21:20:26 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Thu, Jun 17, 2004 at 09:04:39PM -0700, Jon Smirl wrote:
> --- Daniel Stone <[email protected]> wrote:
> > Um, we already have both of these tools deployed on fd.o to build the
> > Xorg tree; Jim set them up a few months ago, in the early days.
>
> Where are the web pages for tinderbox and bonsai? I've been working on
> xserver so I haven't tracked xorg. I just looked on fd.o and x.org and
> can't find them.
http://tinderbox.freedesktop.org
--
Daniel Stone <[email protected]>
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/20040618/6c4b5d78/attach
ment.pgp
From roland.mainz at nrubsig.org Thu Jun 17 21:50:30 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Thu Jun 17 21:50:38 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test theXorg
tree...
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
>
> On Fri, Jun 18, 2004 at 05:36:27AM +0200, Roland Mainz wrote:
> > Is there any interest here in convincing SourcForge to open their
> > compilefarm (read
> > http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
> > firewall (e.g. open the port for CVS that people can do checkouts from
> > pdx.freedesktop.org) that people can use those machines to build and
> > test Xorg/FreeDesktop projects ?
>
> Not really from here; we have a far better portability lab in Debian.
Is it possible that we can use the Debian machines for _debugging_, too
? I need to do some tests on a AMD64/Linux machine and on IRIX + OpenVMS
...
> We
> get reasonable coverage of all the OSes from porters (*BSD, proprietary
> Unices), and Debian covers 14 or 15 architectures or something (trust
> me, it's a lot, and often architectures that upstream doesn't support,
> such as S/390, ARM/Linux, et al). Between those two factors, we cover
> most everything pretty nicely, and we don't have to involve SourceForge.
SourceForge also has FreeBSD, NetBSD, Solaris/x86 etc. compile
machines... my point is that people could test their patches against a
large set of machines...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From daniel at freedesktop.org Thu Jun 17 21:59:30 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Thu Jun 17 21:59:29 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test theXorg
tree...
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Fri, Jun 18, 2004 at 06:50:30AM +0200, Roland Mainz wrote:
> Daniel Stone wrote:
> > On Fri, Jun 18, 2004 at 05:36:27AM +0200, Roland Mainz wrote:
> > > Is there any interest here in convincing SourcForge to open their
> > > compilefarm (read
> > > http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
> > > firewall (e.g. open the port for CVS that people can do checkouts from
> > > pdx.freedesktop.org) that people can use those machines to build and
> > > test Xorg/FreeDesktop projects ?
> >
> > Not really from here; we have a far better portability lab in Debian.
>
> Is it possible that we can use the Debian machines for _debugging_, too
> ? I need to do some tests on a AMD64/Linux machine and on IRIX + OpenVMS
> ...
What sort of tests do you need to do on AMD64?
> > We
> > get reasonable coverage of all the OSes from porters (*BSD, proprietary
> > Unices), and Debian covers 14 or 15 architectures or something (trust
> > me, it's a lot, and often architectures that upstream doesn't support,
> > such as S/390, ARM/Linux, et al). Between those two factors, we cover
> > most everything pretty nicely, and we don't have to involve SourceForge.
>
> SourceForge also has FreeBSD, NetBSD, Solaris/x86 etc. compile
> machines... my point is that people could test their patches against a
> large set of machines...
Sure, but I'm just strongly cautioning against relying on SourceForge.
Try to check something out of their CVS one day, if you want to know
what I mean.
--
Daniel Stone <[email protected]>
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/20040618/287a1052/attach
ment.pgp
From elylevy-xserver at cs.huji.ac.il Fri Jun 18 02:11:23 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Fri Jun 18 02:11:27 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <[email protected]>
Message-ID: <Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il
>
It seems we have a lot of things only 2-3 people knows about
beside compilation farm and bonzai is there anything else cool we want to
know about?;)
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Fri, 18 Jun 2004, Daniel Stone wrote:
> On Thu, Jun 17, 2004 at 08:52:30PM -0700, Jon Smirl wrote:
> > Tinderbox and bonsai are two development tools used in Mozilla. They
> > would also be useful for Xorg. Anyone ambitious enough to set them up?
> >
> > Tinderbox is a good tool for automaticallymaking sure a minimal amount
> > of regression testing occurs for every automated build. Tinderbox is an
> > integral part of the Mozilla development process.
> >
> > http://www.mozilla.org/projects/tinderbox/
From daniel at freedesktop.org Fri Jun 18 02:13:33 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Fri Jun 18 02:13:33 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.i
l>
References: <[email protected]>
<Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il>
Message-ID: <[email protected]>
On Fri, Jun 18, 2004 at 12:11:23PM +0300, Ely Levy wrote:
> It seems we have a lot of things only 2-3 people knows about
> beside compilation farm and bonzai is there anything else cool we want to
> know about?;)
* Debrix.
* Arch.
* Breakdancing.
--
Daniel Stone <[email protected]>
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/20040618/f2f81108/attach
ment-0001.pgp
From elylevy-xserver at cs.huji.ac.il Fri Jun 18 04:02:34 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Fri Jun 18 04:02:38 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Hey,
It seems that next release is going to be an highlighted one,
and I thought we should use it to promote few community projects
which would hopefully help to bring more users/developers to the project.
The idea is project which doesn't take expert programmers and can help new
people finding their way.
1)Doc project
Creating and maintaining docs, translating docs to diffrent langauges
Making howtos and newbie guides (like a newbie guy for X configuration
could be highly helpfull). helping in ordering the wiki and faqs so
people could find help solving their problems.
2)Forum
Yea, a support forum for X, its proven itself to be highly usefull
in creating a community in various projects. Users/Developers help each
other, and more than a few people find it nicer than mailing lists.
3)Xjanitor
For new developers this is the sort of project that would help them
learn about the code while contributing to its general look.
Things like ansifying the code, going over it finding bugs or bad
looking functions and even more importent building a doxygen like
system, now that would help even more experianced developers finding
things around, no?If there would be a coding style guide (whcih could
be nice), making sure the code keep them might also be part of this
project.I'm sure even more ideas would come along.
4)Binary contributers
Nothing much to explain about this one, IMOH we should have binaries
released with every release, there are many platforms and dist we might
want to support, and I'm sure there are a lot of people who would agree
to contribute cpu cycles for making packages, and testing them.
So while the actuall making of the deb or rpm or so might take someone
who knows his way around, the actuall building might be done by people
from the community. I don't know if the various linux/BSD dists would
want to participate, but I have a feeling some of them read this list;)
Comments?:)
Ely Levy
System group
Hebrew University
Jerusalem Israel
From firefly at diku.dk Fri Jun 18 06:35:45 2004
From: firefly at diku.dk (Peter "Firefly" Lund)
Date: Fri Jun 18 06:35:49 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <[email protected]>
References: <[email protected]>
<Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il>
<[email protected]>
Message-ID: <[email protected]>
On Fri, 18 Jun 2004, Daniel Stone wrote:
> On Fri, Jun 18, 2004 at 12:11:23PM +0300, Ely Levy wrote:
> > It seems we have a lot of things only 2-3 people knows about
> > beside compilation farm and bonzai is there anything else cool we want to
> > know about?;)
>
> * Debrix.
> * Arch.
* Darcs
* Hindley-Milner type systems
* Region-based memory management
-Peter
"Their god is a UFO driver. Our group, Revolution Against Evolution, is
made up of traditional Biblical Christians who believe in a supernatural
creator God, and his son Jesus Christ. We in no way believe that this
Christ was a space alien."
-- http://www.rae.org/raelian.html
From Alan.Coopersmith at Sun.COM Fri Jun 18 08:59:23 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Fri Jun 18 08:58:53 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Ely Levy wrote:
> 1)Doc project
> Creating and maintaining docs, translating docs to diffrent langauges
> Making howtos and newbie guides (like a newbie guy for X configuration
> could be highly helpfull). helping in ordering the wiki and faqs so
> people could find help solving their problems.
The first step, which has been discussed elsewhere, is getting all the docs
translated to a common format that can be edited by free software tools,
such as DocBook XML, instead of the multitude of formats currently used,
including some propreitary ones like FrameMaker. ESR's doclifter tool has
been proposed as a way to get started, and then get volunteers to proof/polish
the results.
> 2)Forum
> Yea, a support forum for X, its proven itself to be highly usefull
> in creating a community in various projects. Users/Developers help each
> other, and more than a few people find it nicer than mailing lists.
And yet another large group of people find web forums much worse than mailing
lists. It's a rare website that I can get around to visiting on a regular
basis - forums are just much harder to follow and participate in than a mailing
list or newsgroup. Perhaps that's just proof that we should have both (and
perhaps a gateway between the two) so that users can pick the medium they prefer
.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From elylevy-xserver at cs.huji.ac.il Fri Jun 18 09:04:33 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Fri Jun 18 09:04:39 2004
Subject: [Xorg] Projects suggestions (fwd)
Message-ID: <[email protected]>
> Ely Levy wrote:
> > 1)Doc project
> > Creating and maintaining docs, translating docs to diffrent langauges
> > Making howtos and newbie guides (like a newbie guy for X configuration
> > could be highly helpfull). helping in ordering the wiki and faqs so
> > people could find help solving their problems.
>
> The first step, which has been discussed elsewhere, is getting all the docs
> translated to a common format that can be edited by free software tools,
> such as DocBook XML, instead of the multitude of formats currently used,
> including some propreitary ones like FrameMaker. ESR's doclifter tool has
> been proposed as a way to get started, and then get volunteers to proof/polish
> the results.
Yea, it was moire like idea of what the project should be about than
actuall plan, but I agree it's an important thing.
On the other hand writing docs for newbie users is important thing as
well...
> > 2)Forum
> > Yea, a support forum for X, its proven itself to be highly usefull
> > in creating a community in various projects. Users/Developers help each
> > other, and more than a few people find it nicer than mailing lists.
>
> And yet another large group of people find web forums much worse than mailing
> lists. It's a rare website that I can get around to visiting on a regular
> basis - forums are just much harder to follow and participate in than a mailin
g
> list or newsgroup. Perhaps that's just proof that we should have both (and
> perhaps a gateway between the two) so that users can pick the medium they pref
er.
by no means I ment forum should replace the mailing list,
there is space for both, the way I see it they have completly diffrent
job. Maybe forums would compete news groups but I'm not even sure of
that.
Ely
From jonsmirl at yahoo.com Fri Jun 18 09:17:32 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Fri Jun 18 09:17:35 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Most of the xorg newsgroups are available in news format via the mail
to news gateway at http://www.gmane.org/ Getting the lists in news
format makes it easy to locally archive and search them. If the mailing
list admin ok's it, post to the newsgroups are forwarded back to the
list.
--- Alan Coopersmith <[email protected]> wrote:
> > 2)Forum
> > Yea, a support forum for X, its proven itself to be highly
> usefull
> > in creating a community in various projects. Users/Developers
> help each
> > other, and more than a few people find it nicer than mailing
> lists.
>
> And yet another large group of people find web forums much worse than
> mailing
> lists. It's a rare website that I can get around to visiting on a
> regular
> basis - forums are just much harder to follow and participate in than
> a mailing
> list or newsgroup. Perhaps that's just proof that we should have
> both (and
> perhaps a gateway between the two) so that users can pick the medium
> they prefer.
>
> --
> -Alan Coopersmith- [email protected]
> Sun Microsystems, Inc. - X Window System Engineering
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
From charlie at vexi.org Fri Jun 18 09:59:17 2004
From: charlie at vexi.org (Charles Goodwin)
Date: Fri Jun 18 09:56:18 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Fri, 2004-06-18 at 08:59 -0700, Alan Coopersmith wrote:
> > 2)Forum
>
> And yet another large group of people find web forums much worse than mailing
> lists. It's a rare website that I can get around to visiting on a regular
> basis - forums are just much harder to follow and participate in than a mailin
g
> list or newsgroup. Perhaps that's just proof that we should have both (and
> perhaps a gateway between the two) so that users can pick the medium they pref
er.
Forums are incredibly popular among users where they can dig into
existing discussions without getting the whole lot like you do on a
mailig list. Do not discount them as an effective end-user support
process where users support users and developers get on with their job
on the mailing lists. That is how forums typically work.
I don't think XOrg necessarily needs a forum. Perhaps a freedesktop.org
forum would be better, and could be an interesting place indeed.
--
- Charlie
Charles Goodwin <[email protected]>
Online @ www.charlietech.com
From elanthis at awesomeplay.com Fri Jun 18 10:18:44 2004
From: elanthis at awesomeplay.com (Sean Middleditch)
Date: Fri Jun 18 10:18:54 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Fri, 2004-06-18 at 11:59, Alan Coopersmith wrote:
> And yet another large group of people find web forums much worse than mailing
> lists. It's a rare website that I can get around to visiting on a regular
> basis - forums are just much harder to follow and participate in than a mailin
g
> list or newsgroup. Perhaps that's just proof that we should have both (and
> perhaps a gateway between the two) so that users can pick the medium they pref
er.
One might consider looking at the Google Groups 2 Beta running right
now. Most of the users of my software are the type that prefer forums
over mailing lists, while I myself prefer the mail lists. GG2 merges
them quite nicely; it basically provides a web-based mail archive to a
mailing list with the ability to send new messages to the list using a
web form. You can still require that users sign up to the list before
posting, even on line, and the sign up form makes it very easy to
request no mail for web-only users. Other than the bugs (again, the
service is in beta) it really is quite neat.
http://groups-beta.google.com/
--
Sean Middleditch <[email protected]>
AwesomePlay Productions, Inc.
From thomas at winischhofer.net Fri Jun 18 14:29:12 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Fri Jun 18 14:30:16 2004
Subject: [Xorg] LICENSE file?
Message-ID: <[email protected]>
I certainly don't want to be flamebait here, but IAAL (yes, no "N")
after all:
Is there a LICENSE or COPYING or equivalent file somewhere in the
repository? Is there any file that is also part of the binary
distribution that contains the relevant licenses?
I didn't even find anything the like on x.org at the first glimpse...
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
From charlie at vexi.org Fri Jun 18 14:40:43 2004
From: charlie at vexi.org (Charles Goodwin)
Date: Fri Jun 18 14:37:33 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Fri, 2004-06-18 at 13:18 -0400, Sean Middleditch wrote:
> One might consider looking at the Google Groups 2 Beta running right
> now. .... GG2 merges them quite nicely; it basically provides a
> web-based mail archive to a mailing list with the ability to send
> new messages to the list using a web form.
The only surprising thing is that it has taken so _long_ for somebody to
do something like this.
--
- Charlie
Charles Goodwin <[email protected]>
Online @ www.charlietech.com
From Alan.Coopersmith at Sun.COM Fri Jun 18 15:08:42 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Fri Jun 18 15:09:15 2004
Subject: [Xorg] LICENSE file?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Thomas Winischhofer wrote:
>
> I certainly don't want to be flamebait here, but IAAL (yes, no "N")
> after all:
>
> Is there a LICENSE or COPYING or equivalent file somewhere in the
> repository? Is there any file that is also part of the binary
> distribution that contains the relevant licenses?
It's well hidden: xc/programs/Xserver/hw/xfree86/doc/LICENSE
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From KendallB at scitechsoft.com Fri Jun 18 16:16:00 2004
From: KendallB at scitechsoft.com (Kendall Bennett)
Date: Fri Jun 18 16:20:56 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: <40D181FC.19795.2CD055E8@localhost>
References: <[email protected]>
Message-ID: <40D31540.22608.32F798A1@localhost>
No response to my question? I would like to find out what we should do
before we ship our product ;-)
> Hey Guys,
>
> I have been quiet on these mailing lists for a while as we have been
> slaving away on PowerPC support in our products. I am back working on our
> X Server drivers again, and working on adding support for the X.org
> servers. Part of our previous installer detects the installed XFree86
> version to determine which module we should be installing. To do this we
> look at the 'X -version' string and parse the XFree86 version number from
> that.
>
> Looking at the Xorg server output for the -version command it appears all
> that changed was the first string that contained the XFree86 version
> indentifier was removed, and the Release was upped to 6.7 from 6.6. I can
> easily detect the initial X.org release by looking at the 6.7 string, but
> I need to know if this version number is going to be revved for each
> X.org official release.
>
> Ie: will the next release from X.org be versioned as R6.8? If not, we
> need to seriously considering putting some kind of release versioning
> into the X server so third party driver installers like ours can detect
> the server version correctly and install the correct driver modules based
> on that information.
>
> For now I will assume the 6.7 will change to 6.8, so I can get our
> installer done. If that isn't the case we will need to fix it before the
> next release ;-)
>
> Regards,
>
> ---
> Kendall Bennett
> Chief Executive Officer
> SciTech Software, Inc.
> Phone: (530) 894 8400
> http://www.scitechsoft.com
>
> ~ SciTech SNAP - The future of device driver technology! ~
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
From charlie at vexi.org Fri Jun 18 17:31:24 2004
From: charlie at vexi.org (Charles Goodwin)
Date: Fri Jun 18 17:28:06 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: <40D31540.22608.32F798A1@localhost>
References: <[email protected]>
<40D31540.22608.32F798A1@localhost>
Message-ID: <[email protected]>
On Fri, 2004-06-18 at 16:16 -0700, Kendall Bennett wrote:
> No response to my question? I would like to find out what we should do
> before we ship our product ;-)
I really don't think it's unreasonable to assume that the version number
will be revved with each release, even if it's only revved to 6.7.x it
definitely will change. How can you have two releases against the same
version number? That's just illogical. Jim.
--
- Charlie
Charles Goodwin <[email protected]>
Online @ www.charlietech.com
From KendallB at scitechsoft.com Fri Jun 18 18:19:19 2004
From: KendallB at scitechsoft.com (Kendall Bennett)
Date: Fri Jun 18 18:24:13 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: <[email protected]>
References: <40D31540.22608.32F798A1@localhost>
Message-ID: <40D33227.18712.336880BE@localhost>
Charles Goodwin <[email protected]> wrote:
> On Fri, 2004-06-18 at 16:16 -0700, Kendall Bennett wrote:
> > No response to my question? I would like to find out what we should do
> > before we ship our product ;-)
>
> I really don't think it's unreasonable to assume that the version number
> will be revved with each release, even if it's only revved to 6.7.x it
> definitely will change. How can you have two releases against the same
> version number? That's just illogical. Jim.
That would be my thinking also. However if the versioning system is going
to be three digits rather than two (ie: next release is 6.7.1), then my
code will have to be adapted to expect three digits in the version
number.
Personally I prefer the three digit system so the next release should be
6.7.1, but if a new version is completed that is big enough to warrant a
change to 6.8, it should be 6.8.0 rather than 6.8 (otherwise my scripts
will get rather confused!).
Hence the reason I am asking ;-)
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
From roland.mainz at nrubsig.org Fri Jun 18 18:38:24 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Fri Jun 18 18:38:34 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test
theXorgtree...
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> > > On Fri, Jun 18, 2004 at 05:36:27AM +0200, Roland Mainz wrote:
> > > > Is there any interest here in convincing SourcForge to open their
> > > > compilefarm (read
> > > > http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1)
> > > > firewall (e.g. open the port for CVS that people can do checkouts from
> > > > pdx.freedesktop.org) that people can use those machines to build and
> > > > test Xorg/FreeDesktop projects ?
> > >
> > > Not really from here; we have a far better portability lab in Debian.
> >
> > Is it possible that we can use the Debian machines for _debugging_, too
> > ? I need to do some tests on a AMD64/Linux machine and on IRIX + OpenVMS
> > ...
>
> What sort of tests do you need to do on AMD64?
AMD64 test of Xprt+GLX and one of the "heisenbugs" related to CUPS when
the *BSD-compat. package isn't installed. I only need shell access and
all tools required to build the Xorg tree...
> > > We
> > > get reasonable coverage of all the OSes from porters (*BSD, proprietary
> > > Unices), and Debian covers 14 or 15 architectures or something (trust
> > > me, it's a lot, and often architectures that upstream doesn't support,
> > > such as S/390, ARM/Linux, et al). Between those two factors, we cover
> > > most everything pretty nicely, and we don't have to involve SourceForge.
> >
> > SourceForge also has FreeBSD, NetBSD, Solaris/x86 etc. compile
> > machines... my point is that people could test their patches against a
> > large set of machines...
>
> Sure, but I'm just strongly cautioning against relying on SourceForge.
> Try to check something out of their CVS one day, if you want to know
> what I mean.
Uhm... what exact problem do you mean ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From Alan.Coopersmith at Sun.COM Fri Jun 18 19:44:49 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Fri Jun 18 19:45:23 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: <40D33227.18712.336880BE@localhost>
References: <40D31540.22608.32F798A1@localhost>
<40D33227.18712.336880BE@localhost>
Message-ID: <[email protected]>
Kendall Bennett wrote:
> That would be my thinking also. However if the versioning system is going
> to be three digits rather than two (ie: next release is 6.7.1), then my
> code will have to be adapted to expect three digits in the version
> number.
>
> Personally I prefer the three digit system so the next release should be
> 6.7.1, but if a new version is completed that is big enough to warrant a
> change to 6.8, it should be 6.8.0 rather than 6.8 (otherwise my scripts
> will get rather confused!).
We've talked about doing a 6.7.1 bug fix release, but we've also talked about
the next release including some pretty big changes (such as Composite & Damage),
in which case 6.8.0 would make more sense. In either case, I would expect the
next release will not be 6.7.0 and that you should expect 3-digit releases at
some point in the future.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From charlie at vexi.org Fri Jun 18 20:05:18 2004
From: charlie at vexi.org (Charles Goodwin)
Date: Fri Jun 18 20:02:02 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test
theXorgtree...
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
On Sat, 2004-06-19 at 03:38 +0200, Roland Mainz wrote:
> > Sure, but I'm just strongly cautioning against relying on SourceForge.
> > Try to check something out of their CVS one day, if you want to know
> > what I mean.
>
> Uhm... what exact problem do you mean ?
SF have a less-than-stellar reputation for having reliable service,
mainly stemming from their problems with anonymous CVS access which is
frequently down and pretty much always way out of date by 24-48 hours.
That's the word on the grapevine, at least.
--
- Charlie
Charles Goodwin <[email protected]>
Online @ www.charlietech.com
From keithp at keithp.com Fri Jun 18 21:18:51 2004
From: keithp at keithp.com (Keith Packard)
Date: Fri Jun 18 21:19:32 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: Your message of "Fri, 18 Jun 2004 16:16:00 PDT."
<40D31540.22608.32F798A1@localhost>
Message-ID: <[email protected]>
Around 16 o'clock on Jun 18, "Kendall Bennett" wrote:
> No response to my question? I would like to find out what we should do
> before we ship our product ;-)
Last I heard, the next X.Org release was going to be either 6.7.1 or 6.8.
It will certainly have a larger number than 6.7 though.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040618/bf6f2ddb/attach
ment.pgp
From keithp at keithp.com Fri Jun 18 21:23:42 2004
From: keithp at keithp.com (Keith Packard)
Date: Fri Jun 18 21:24:12 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: Your message of "Fri, 18 Jun 2004 18:19:19 PDT."
<40D33227.18712.336880BE@localhost>
Message-ID: <[email protected]>
Around 18 o'clock on Jun 18, "Kendall Bennett" wrote:
> it should be 6.8.0 rather than 6.8 (otherwise my scripts
> will get rather confused!).
I suspect you'll want to fix your scripts to accept a shorter version as
equivalent to the longer version with trailing zeros; when a '6.8' release
does come out, it'll probably be '6.8' and not '6.8.0'.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040618/02754f23/attach
ment.pgp
From erikharrison at gmail.com Sat Jun 19 13:53:32 2004
From: erikharrison at gmail.com (Erik Harrison)
Date: Sat Jun 19 13:53:55 2004
Subject: [Xorg] Projects suggestions
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Fri, 18 Jun 2004 08:59:23 -0700, Alan Coopersmith
<[email protected]> wrote:
>
> Ely Levy wrote:
> > 1)Doc project
> > Creating and maintaining docs, translating docs to diffrent langauges
> > Making howtos and newbie guides (like a newbie guy for X configuration
> > could be highly helpfull). helping in ordering the wiki and faqs so
> > people could find help solving their problems.
>
> The first step, which has been discussed elsewhere, is getting all the docs
> translated to a common format that can be edited by free software tools,
> such as DocBook XML, instead of the multitude of formats currently used,
> including some propreitary ones like FrameMaker. ESR's doclifter tool has
> been proposed as a way to get started, and then get volunteers to proof/polish
> the results.
>
> > 2)Forum
> > Yea, a support forum for X, its proven itself to be highly usefull
> > in creating a community in various projects. Users/Developers help each
> > other, and more than a few people find it nicer than mailing lists.
>
> And yet another large group of people find web forums much worse than mailing
> lists. It's a rare website that I can get around to visiting on a regular
> basis - forums are just much harder to follow and participate in than a mailin
g
> list or newsgroup. Perhaps that's just proof that we should have both (and
> perhaps a gateway between the two) so that users can pick the medium they pref
er.
>
One of the nifty things about a forum is the low barrier to entry. If
the Xorg mailing list is flooded with support questions, then it's
hard for the mailing list to be productive. A forum makes it easy for
people to post questions and answers without their discussions
interfering with others. Of course, that's the reason that forum
discussions are generally less thoughtful that mailing lists.
A forum helps make it obvious where the software is deficient with
Joe User, and provides peer to peer support. I don't think it needs to
be tied to the mailing list - the opposite in fact.
-Erik "lurk lurk lurk" Harrison
> --
> -Alan Coopersmith- [email protected]
> Sun Microsystems, Inc. - X Window System Engineering
>
>
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From alan at lxorguk.ukuu.org.uk Sat Jun 19 13:57:51 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sat Jun 19 15:00:57 2004
Subject: [Xorg] Using SourceForge's compile farm to build and test
theXorg tree...
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
On Gwe, 2004-06-18 at 05:50, Roland Mainz wrote:
> Is it possible that we can use the Debian machines for _debugging_, too
> ? I need to do some tests on a AMD64/Linux machine and on IRIX + OpenVMS
> ...
I can probably help with AMD64 testing providing I know what
needs testing. Giving access direct to an AMD64 box is doable but I'd
prefer someone I trust to vouch for you first
From alan at lxorguk.ukuu.org.uk Sat Jun 19 13:59:30 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Sat Jun 19 15:02:36 2004
Subject: [Xorg] Voodoo 1 & 2 Driver
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
I'd like commit this driver to CVS head now I am happy with it. Should I
just commit it or would one of the elders like to review it first ?
Alan
From keithp at keithp.com Sat Jun 19 15:09:31 2004
From: keithp at keithp.com (Keith Packard)
Date: Sat Jun 19 15:10:41 2004
Subject: [Xorg] Voodoo 1 & 2 Driver
In-Reply-To: Your message of "Sat, 19 Jun 2004 21:59:30 BST."
<[email protected]>
Message-ID: <[email protected]>
Around 21 o'clock on Jun 19, Alan Cox wrote:
> I'd like commit this driver to CVS head now I am happy with it. Should I
> just commit it or would one of the elders like to review it first ?
If it's a new driver that no-one else is using, feel free to commit at
will. The only time changes need reviewing is when you're modifying bits
beyond your ken.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040619/ebc73c2f/attach
ment.pgp
From asterius at airpost.net Sat Jun 19 18:34:44 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Sat Jun 19 18:34:47 2004
Subject: [Xorg] Missing X libraries and headers?
Message-ID: <[email protected]>
While trying to compile fluxbox got the following error : Missing X
libraries and headers. I'm trying to get it working on top of Xvesa. Any
suggestions? Thanks.
Asterius.
From eta at lclark.edu Sun Jun 20 03:01:20 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sun Jun 20 03:01:56 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: <[email protected]>
References: <[email protected]>
<Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il>
<[email protected]>
Message-ID: <1087725680.1032.144.camel@leguin>
On Fri, 2004-06-18 at 02:13, Daniel Stone wrote:
> On Fri, Jun 18, 2004 at 12:11:23PM +0300, Ely Levy wrote:
> > It seems we have a lot of things only 2-3 people knows about
> > beside compilation farm and bonzai is there anything else cool we want to
> > know about?;)
>
> * Debrix.
> * Arch.
> * Breakdancing.
I couldn't think of anything before, but was reminded tonight on irc.
cvsup!
cvsup lets you check out a branch of cvs, or lets you check out the
entire repository to your local system. With the repository on your
system, you can practice those things that are easy to screw up, like
imports, and lets you check out other branches, cvs diff, or update -j
without hitting the network. Plus it goes faster than a regular cvs
update. It's set up already for xorg, xserver, xlibs, xapps, and dri,
at least (sample supfile attached).
Sure, it's not as great as ${YOUR_FAV_SCM}, but it's something that can
be used right now, in the current environment, to improve developers'
experiences, without having to go through the same argument about SCMs
that happens every 3 months and us coming to the same conclusion that
nobody can agree on what the best SCM is and that we'd alienate userbase
and/or new developers by using ${SCM_FEW_ALREADY_USE}.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
-------------- next part --------------
*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
From mark at hymers.org.uk Sun Jun 20 03:38:23 2004
From: mark at hymers.org.uk (Mark Hymers)
Date: Sun Jun 20 03:38:22 2004
Subject: [Xorg] buildem patch for the modular xlibs tree
Message-ID: <[email protected]>
Hi,
Attached is a patch for the buildem script which makes the version
checks honour the AUTOMAKE, AUTOCONF and LIBTOOLIZE variables (as
autoreconf itself does). It also adds support for definining a
seperate installation root and exports the relevant PKG_CONFIG_PATH
variable so that users can build packages in their home directory.
Oh, and I fixed the cvs call - for some reason my version of cvs (Debian
Unstable) doesn't like the branch name coming after the repository
name...
Hope this is useful
Mark
--
Mark Hymers <markh at linuxfromscratch dot org>
"Everyone is entitled to be stupid but some abuse the privilege."
Unknown
-------------- next part --------------
Index: build-em
===================================================================
RCS file: /cvs/xlibs/xlibs/build-em,v
retrieving revision 1.7
diff -u -p -r1.7 build-em
--- build-em 19 May 2004 05:05:06 -0000 1.7
+++ build-em 20 Jun 2004 10:24:14 -0000
@@ -1,24 +1,53 @@
#!/bin/sh
set -e

-# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
+INST_ROOT=/usr/local
+export PKG_CONFIG_PATH=$INST_ROOT/lib/pkgconfig

## Uncomment this to perform the "make install" step using sudo
#BUILD_EM_SUDO=sudo

-if automake --version | grep 'automake' | grep -q '1\.7'; then
+# You can set the following variable to set the path to the the autofoo
+# programs and they will be honoured by autoreconf
+#
+# The usual way of using this is to export the variables before calling
+# this script. It is very useful on Debian where it's necessary to
+# export AUTOMAKE=automake-1.7 export ACLOCAL=aclocal-1.7
+# in order to use the correct version of automake
+#
+# $AUTOMAKE $ACLOCAL
+# $AUTOCONF $AUTOHEADER
+# $LIBTOOLIZE
+# $AUTOPOINT
+
+# Default to checking the default command names for their versions
+# if not overridden by environment variables
+if [ -z $AUTOMAKE ]; then
+ AUTOMAKE=automake
+fi
+
+if [ -z $AUTOCONF ]; then
+ AUTOCONF=autoconf
+fi
+
+if [ -z $LIBTOOLIZE ]; then
+ LIBTOOLIZE=libtoolize
+fi
+
+
+if $AUTOMAKE --version | grep 'automake' | grep -q '1\.7'; then
echo 'found automake 1.7'
else
echo 'automake is not version 1.7'
exit 1
fi
-if autoconf --version | grep 'autoconf' | grep -q '2\.5'; then
+if $AUTOCONF --version | grep 'autoconf' | grep -q '2\.5'; then
echo 'found autoconf 2.5 or better'
else
echo 'autoconf is not 2.5 or better'
exit 1
fi
-if libtoolize --version | grep 'libtool' | grep -q '1\.5'; then
+if $LIBTOOLIZE --version | grep 'libtool' | grep -q '1\.5'; then
echo 'found libtool 1.5'
else
echo 'libtool 1.5 is not or better'
@@ -33,12 +62,12 @@ PACKAGES=`cat Packages | while read i; d
esac
done`
echo "Checking out xtrans with forced tag XTRANS-0_1-RELEASE"
-cvs co xtrans -r XTRANS-0_1-RELEASE
+cvs co -r XTRANS-0_1-RELEASE xtrans
pushd xtrans
if [ $# -gt 0 ] ||
[ configure.ac -nt config.status ] ||
[ Makefile.am -nt config.status ]; then
- ./autogen.sh "$@"
+ ./autogen.sh --prefix=$INST_ROOT "$@"
fi
make -j2
$BUILD_EM_SUDO make install
@@ -52,7 +81,7 @@ for i in $PACKAGES; do
if [ $# -gt 0 ] ||
[ configure.ac -nt config.status ] ||
[ Makefile.am -nt config.status ]; then
- ./autogen.sh "$@"
+ ./autogen.sh --prefix=$INST_ROOT "$@"
fi
make -j2
$BUILD_EM_SUDO make install
From eta at lclark.edu Sun Jun 20 11:27:56 2004
From: eta at lclark.edu (Eric Anholt)
Date: Sun Jun 20 11:28:34 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
Message-ID: <1087756076.887.1.camel@leguin>
On Sun, 2004-06-20 at 11:17, Ian Molton wrote:
> On Thu, 17 Jun 2004 11:00:33 -0700
> Alan Coopersmith <[email protected]> wrote:
>
> > The big dri merge seems a good time to label snapshot 6.7.0.90 or
> > however we want to start identifying the pre-6.7.1 snapshots. (How
> > do we want to do that?)
>
> that .90 numbering is hideous. whats wrong with -preX ?
Yeah, here's a vote for that, as well. And for tarring a snapshot at
this point, if we could.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From daniel at freedesktop.org Sun Jun 20 11:40:12 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 20 11:40:11 2004
Subject: [Xorg] Introduce DRI_VERSION?
In-Reply-To: <1087756076.887.1.camel@leguin>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<1087756076.887.1.camel@leguin>
Message-ID: <[email protected]>
On Sun, Jun 20, 2004 at 11:27:56AM -0700, Eric Anholt wrote:
> On Sun, 2004-06-20 at 11:17, Ian Molton wrote:
> > On Thu, 17 Jun 2004 11:00:33 -0700
> > Alan Coopersmith <[email protected]> wrote:
> >
> > > The big dri merge seems a good time to label snapshot 6.7.0.90 or
> > > however we want to start identifying the pre-6.7.1 snapshots. (How
> > > do we want to do that?)
> >
> > that .90 numbering is hideous. whats wrong with -preX ?
>
> Yeah, here's a vote for that, as well. And for tarring a snapshot at
> this point, if we could.
It doesn't fit into x.y.z.a, that's why. Internally, KDE at least maps
its versions to numbers (e.g. 3.0a1 -> 2.99.1/029901). Also sucks for us
packagers (2.9+3.0alpha1 as version numbers are horrific, and this
braindamage is all through Debian). I see the argument for it, but the
argument against is compelling; in this case we need numeracy anyway, so
we might as well shoot for consistency.
--
Daniel Stone <[email protected]>
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/20040621/2d6e8492/attach
ment.pgp
From keith at tungstengraphics.com Mon Jun 21 06:45:38 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Mon Jun 21 06:45:50 2004
Subject: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
Message-ID: <[email protected]>
-------------- next part --------------
An embedded message was scrubbed...
From: Keith Whitwell <[email protected]>
Subject: Re: CVS Update: xc (branch: trunk)
Date: Mon, 21 Jun 2004 14:44:53 +0100
Size: 1684
Url: http://freedesktop.org/pipermail/xorg/attachments/20040621/a9da9ba4/trunk.m
ht
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jun 21 07:03:09 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Jun 21 07:03:14 2004
Subject: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, 21 Jun 2004, Keith Whitwell wrote:
> I haven't looked at this change yet, but I'm leery of downstream modifications

> to extras/Mesa/*. If the change to GL/gl.h is warranted, it should be
> submitted as a patch to Mesa. This is a key file and changes to it are
> closely monitored & must be well understood and justified.

> As it stands, I believe Mesa builds & runs on windows without modification.
This is not a change for win32 but for cygwin. Cygwin by default does not use
stdcall semantics but this is required if we wish to link to the windows opengl3
2
library.
The patch only changes the GLAPIENTRY macro to use __stdcall if USE_OPENGL32 is
defined.
If it is required, I'll send it as a patch to mesa too.
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From keith at tungstengraphics.com Mon Jun 21 07:46:02 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Mon Jun 21 07:46:13 2004
Subject: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alexander Gottwald wrote:
> On Mon, 21 Jun 2004, Keith Whitwell wrote:
>
>
>>I haven't looked at this change yet, but I'm leery of downstream modifications

>>to extras/Mesa/*. If the change to GL/gl.h is warranted, it should be
>>submitted as a patch to Mesa. This is a key file and changes to it are
>>closely monitored & must be well understood and justified.
>
>
>
>>As it stands, I believe Mesa builds & runs on windows without modification.
>
>
> This is not a change for win32 but for cygwin. Cygwin by default does not use
> stdcall semantics but this is required if we wish to link to the windows openg
l32
> library.
>
> The patch only changes the GLAPIENTRY macro to use __stdcall if USE_OPENGL32 i
s
> defined.
>
> If it is required, I'll send it as a patch to mesa too.
That should be done by changing the definition of GLAPIENTRY - I haven't
looked at the change as I said, but it is 500+ lines of differences.
Keith
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jun 21 07:51:40 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Jun 21 07:51:43 2004
Subject: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 21 Jun 2004, Keith Whitwell wrote:
> Alexander Gottwald wrote:
> > On Mon, 21 Jun 2004, Keith Whitwell wrote:
> >
> >
> >>I haven't looked at this change yet, but I'm leery of downstream modificatio
ns
> >>to extras/Mesa/*. If the change to GL/gl.h is warranted, it should be
> >>submitted as a patch to Mesa. This is a key file and changes to it are
> >>closely monitored & must be well understood and justified.
> >
> >
> >
> >>As it stands, I believe Mesa builds & runs on windows without modification.
> >
> >
> > This is not a change for win32 but for cygwin. Cygwin by default does not us
e
> > stdcall semantics but this is required if we wish to link to the windows ope
ngl32
> > library.
> >
> > The patch only changes the GLAPIENTRY macro to use __stdcall if USE_OPENGL32
is
> > defined.
> >
> > If it is required, I'll send it as a patch to mesa too.
>
> That should be done by changing the definition of GLAPIENTRY - I haven't
> looked at the change as I said, but it is 500+ lines of differences.
This is between 1.1 and 1.2
The actual change is
$ cvs diff -kk -r 1.1.1.3 -r 1.2 gl.h
Index: gl.h
===================================================================
RCS file: /cvs/xorg/xc/extras/Mesa/include/GL/gl.h,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -u -r1.1.1.3 -r1.2
--- gl.h 16 Jun 2004 09:16:30 -0000 1.1.1.3
+++ gl.h 21 Jun 2004 13:35:05 -0000 1.2
@@ -61,6 +61,9 @@
# define GLAPI extern
# endif /* _STATIC_MESA support */
# define GLAPIENTRY __stdcall
+#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native windows opengl
32 */
+# define GLAPI extern
+# define GLAPIENTRY __stdcall
#else
/* non-Windows compilation */
# define GLAPI extern
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From keith at tungstengraphics.com Mon Jun 21 08:37:35 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Mon Jun 21 08:37:50 2004
Subject: [Mesa3d-dev] Re: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Keith Whitwell wrote:
> Alexander Gottwald wrote:
>
>> On Mon, 21 Jun 2004, Keith Whitwell wrote:
>>
>>
>>> Alexander Gottwald wrote:
>>>
>>>> On Mon, 21 Jun 2004, Keith Whitwell wrote:
>>>>
>>>>
>>>>
>>>>> I haven't looked at this change yet, but I'm leery of downstream
>>>>> modifications to extras/Mesa/*. If the change to GL/gl.h is
>>>>> warranted, it should be submitted as a patch to Mesa. This is a
>>>>> key file and changes to it are closely monitored & must be well
>>>>> understood and justified.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> As it stands, I believe Mesa builds & runs on windows without
>>>>> modification.
>>>>
>>>>
>>>>
>>>> This is not a change for win32 but for cygwin. Cygwin by default
>>>> does not use
>>>> stdcall semantics but this is required if we wish to link to the
>>>> windows opengl32 library.
>>>>
>>>> The patch only changes the GLAPIENTRY macro to use __stdcall if
>>>> USE_OPENGL32 is defined.
>>>> If it is required, I'll send it as a patch to mesa too.
>>>
>>>
>>> That should be done by changing the definition of GLAPIENTRY - I
>>> haven't looked at the change as I said, but it is 500+ lines of
>>> differences.
>>
>>
>>
>> This is between 1.1 and 1.2
>>
>> The actual change is
>> $ cvs diff -kk -r 1.1.1.3 -r 1.2 gl.h
>> Index: gl.h
>> ===================================================================
>> RCS file: /cvs/xorg/xc/extras/Mesa/include/GL/gl.h,v
>> retrieving revision 1.1.1.3
>> retrieving revision 1.2
>> diff -u -r1.1.1.3 -r1.2
>> --- gl.h 16 Jun 2004 09:16:30 -0000 1.1.1.3
>> +++ gl.h 21 Jun 2004 13:35:05 -0000 1.2
>> @@ -61,6 +61,9 @@
>> # define GLAPI extern
>> # endif /* _STATIC_MESA support */
>> # define GLAPIENTRY __stdcall
>> +#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native
>> windows opengl32 */
>> +# define GLAPI extern
>> +# define GLAPIENTRY __stdcall
>> #else
>> /* non-Windows compilation */
>> # define GLAPI extern
>>
>> bye
>> ago
>
>
> Why are you comparing 1.1.13 and 1.2? Surely the appropriate
> appropriate comparison is between 1.1 and 1.2?
>
> The results of the 1.1/1.2 diff are too large to post, but correspond
> well with the numbers (+547 -876) that went out in the original CVS
> message. Is it possible that you have inadvertently made a bigger
> change than you intended, eg. by backing out parts of the recent Mesa
> merge?
Actually, it looks like this is part of the Mesa merge which was previously on
the branch (1.1.1.3) and has now escaped to the trunk. In any case it looks
like you've made a bigger-than-intended change to the trunk.
Keith
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jun 21 08:49:02 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Jun 21 08:49:06 2004
Subject: [Mesa3d-dev] Re: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
On Mon, 21 Jun 2004, Keith Whitwell wrote:
> >> This is between 1.1 and 1.2
> >>
> >> The actual change is
> >> $ cvs diff -kk -r 1.1.1.3 -r 1.2 gl.h
> >> Index: gl.h
> >> ===================================================================
> >> RCS file: /cvs/xorg/xc/extras/Mesa/include/GL/gl.h,v
> >> retrieving revision 1.1.1.3
> >> retrieving revision 1.2
> >> diff -u -r1.1.1.3 -r1.2
> >> --- gl.h 16 Jun 2004 09:16:30 -0000 1.1.1.3
> >> +++ gl.h 21 Jun 2004 13:35:05 -0000 1.2
> >> @@ -61,6 +61,9 @@
> >> # define GLAPI extern
> >> # endif /* _STATIC_MESA support */
> >> # define GLAPIENTRY __stdcall
> >> +#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native
> >> windows opengl32 */
> >> +# define GLAPI extern
> >> +# define GLAPIENTRY __stdcall
> >> #else
> >> /* non-Windows compilation */
> >> # define GLAPI extern
> >>
> >> bye
> >> ago
> >
> >
> > Why are you comparing 1.1.13 and 1.2? Surely the appropriate
> > appropriate comparison is between 1.1 and 1.2?
> >
> > The results of the 1.1/1.2 diff are too large to post, but correspond
> > well with the numbers (+547 -876) that went out in the original CVS
> > message. Is it possible that you have inadvertently made a bigger
> > change than you intended, eg. by backing out parts of the recent Mesa
> > merge?
>
> Actually, it looks like this is part of the Mesa merge which was previously on

> the branch (1.1.1.3) and has now escaped to the trunk. In any case it looks
> like you've made a bigger-than-intended change to the trunk.
1.1.1.3 is on the vendor branch. This means the order of revisions was 1.1, 1.1.
1.3,
1.2. The yesterdays head revision was 1.1.1.3
$ cvs diff -D yesterday -D now gl.h
Index: gl.h
===================================================================
RCS file: /cvs/xorg/xc/extras/Mesa/include/GL/gl.h,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -u -r1.1.1.3 -r1.2
--- gl.h 16 Jun 2004 09:16:30 -0000 1.1.1.3
+++ gl.h 21 Jun 2004 13:35:05 -0000 1.2
@@ -61,6 +61,9 @@
# define GLAPI extern
# endif /* _STATIC_MESA support */
# define GLAPIENTRY __stdcall
+#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native windows opengl
32 */
+# define GLAPI extern
+# define GLAPIENTRY __stdcall
#else
/* non-Windows compilation */
# define GLAPI extern
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jun 21 09:00:23 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Jun 21 09:00:26 2004
Subject: [Mesa3d-dev] Re: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, 21 Jun 2004, Keith Whitwell wrote:
> Ugh, ok. Apologies for scare-mongering.
No problem
> Yes, I think this patch should be submitted to Mesa,
I'll do that

> and yes, I think that the CVS mailing list message is a
> little confusing.
me too.
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From eta at lclark.edu Mon Jun 21 11:12:59 2004
From: eta at lclark.edu (Eric Anholt)
Date: Mon Jun 21 11:13:37 2004
Subject: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <1087841579.890.11.camel@leguin>
On Mon, 2004-06-21 at 07:46, Keith Whitwell wrote:
> Alexander Gottwald wrote:
> > On Mon, 21 Jun 2004, Keith Whitwell wrote:
> >
> >
> >>I haven't looked at this change yet, but I'm leery of downstream modificatio
ns
> >>to extras/Mesa/*. If the change to GL/gl.h is warranted, it should be
> >>submitted as a patch to Mesa. This is a key file and changes to it are
> >>closely monitored & must be well understood and justified.
> >
> >
> >
> >>As it stands, I believe Mesa builds & runs on windows without modification.
> >
> >
> > This is not a change for win32 but for cygwin. Cygwin by default does not us
e
> > stdcall semantics but this is required if we wish to link to the windows ope
ngl32
> > library.
> >
> > The patch only changes the GLAPIENTRY macro to use __stdcall if USE_OPENGL32
is
> > defined.
> >
> > If it is required, I'll send it as a patch to mesa too.
>
> That should be done by changing the definition of GLAPIENTRY - I haven't
> looked at the change as I said, but it is 500+ lines of differences.
This is the effect of taking something off the vendor branch. Instead
of getting the difference between the previous revision you would have
used (1.1.1.3) and the new revision (1.2), you get the diff listed
between the previous HEAD version (1.1) and the new revision 1.2.
Now, any time someone imports new Mesa, they'll have to manually merge
this file, and resolve conflicts in this file I think. This is one
reason that taking things off the vendor branch that are updated from
the vendor is *strongly* discouraged. I should have sent out a note
about this with the merge I did, but oh well. Anyway, the best way to
deal with these things is to get the change into the vendor's tree, and
then either import it to our tree, or just import the fix itself on the
vendor branch knowing that it won't be wiped out with the next full
import. If this fix gets merged to Mesa (such that no differences were
necessary between the vendor branch and HEAD), I think we can cvs admin
the file back onto the vendor branch and avoid any future merging mess
there.
Anyway, this is all what I understand. I'll admit I'm still not fully
clued into vendor branch stuff, I've just listened to FreeBSD lists a
lot where a lot of attention is paid to this.
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From ml_gupta at hotmail.com Mon Jun 21 12:02:42 2004
From: ml_gupta at hotmail.com (Manish Gupta)
Date: Mon Jun 21 12:03:03 2004
Subject: [Xorg] FC2 ATI Radeon 7000 and TV-Out
Message-ID: <[email protected]>
Recently, I upgraded from FC2 Test2 to FC2. Unfortunately, the TV-Out
functionality stoppped working after this upgrade. I am using Radeon
7000 card. In the FC2 Test2 I used Gatos TV_OUTPUT. That does not seem
to be an option anymore. Now, when I connect my machine to the TV, it shows
blue random lines. I also tinkered with different Modelines with no success.
I also looked at the radeon documentation page at freedesktop.org.
Unfortunately, I could not figure out options that would make TV-Out
functionality work again.
Any help in this regard would be really appreciated.
Thanks
Below is an excerpt from my /etc/X11/XF86Config:
--------------------------------
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Dell M782"
DisplaySize 330 240
HorizSync 30.0 - 85.0
VertRefresh 50.0 - 160.0
Option "dpms"
EndSection
Section "Device"
Identifier "Videocard0"
Driver "radeon"
VendorName "Videocard vendor"
BoardName "ATI Radeon 7000"
Option "TVOutput" "NTSC"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "800x600" "640x480"
EndSubSection
EndSection
Section "DRI"
Group 0
Mode 0666
EndSection
-------------------
Manish
_________________________________________________________________
Get fast, reliable Internet access with MSN 9 Dial-up now 3 months FREE!
http://join.msn.click-url.com/go/onm00200361ave/direct/01/
From KendallB at scitechsoft.com Mon Jun 21 15:45:35 2004
From: KendallB at scitechsoft.com (Kendall Bennett)
Date: Mon Jun 21 15:50:24 2004
Subject: [Xorg] Detecting server version?
In-Reply-To: <[email protected]>
References: Your message of "Fri,
18 Jun 2004 18:19:19 PDT." <40D33227.18712.336880BE@localhost>
Message-ID: <40D7029F.17529.424ED38A@localhost>
Keith Packard <[email protected]> wrote:
> > it should be 6.8.0 rather than 6.8 (otherwise my scripts
> > will get rather confused!).
>
> I suspect you'll want to fix your scripts to accept a shorter
> version as equivalent to the longer version with trailing zeros;
> when a '6.8' release does come out, it'll probably be '6.8' and
> not '6.8.0'.
Ok, good to know. I will fix my scripts to handle both and essentially
turn it into 6.8.0 if the last digit is missing ;-)
Thanks!
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
From ateixeira at insignesoftware.com Mon Jun 21 16:39:56 2004
From: ateixeira at insignesoftware.com (Alexandre P. Teixeira)
Date: Mon Jun 21 16:34:24 2004
Subject: [Xorg] Local Multi Users
Message-ID: <[email protected]>
Hello,
I hereby come to ask for help in my necessity of developping a
open-source money-saving project
for educational purposes in our poor communities.
The main goal is to be able to use one computer with 5 monitors. That
way, we can buy one
computer and use it with five different monitors to simulate five
separate computer desktops
for teaching.
We have found some documentation on:
http://cambuca.ldhs.cetuc.puc-rio.br/multiuser
telling us how to do that in XFree86-4xx. This method works, but when we
load 'gdm' and
a user disconnects from gdm from one desktop, all the others will freeze.
We have had some
other problems which made us consider alternatives.
We are thinking of migrating to X.org but we don't know it nor we found
any documentation about a
similar process in it (if it's at all possible).
So we ask for guidance as to how to proceed and how to find out if this
task can be made in X.org.
Trully Yours,
Alexandre Penasso Teixeira
From asterius at airpost.net Mon Jun 21 17:28:53 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Mon Jun 21 17:28:57 2004
Subject: [Xorg] Xvesa & fluxbox (again)
Message-ID: <[email protected]>
When I try to start fluxbox /usr/X11R6/bin/Xvesa -screen 1400x1050x16 &
fluxbox, it says can't connect to X server. Make sure you start X before
the Fluxbox. I can run /usr/X11R6/bin/Xvesa -screen 1400x1050x16 & aterm
though and after I call fluxbox inside of aterm, fluxbox starts just
fine. How do I start fluxbox on a command line? Any suggestions? Another
thing is that I'm trying to migrate to ratpoison and, as with fluxbox,
ratpoison can't connect to X and when I call it from inside of aterm, it
complains about 7x16bold fonts. Where in general Xserver font path?
As always, thanks everyone for any suggestions.
Asterius.
From chris at adebenham.com Mon Jun 21 17:45:21 2004
From: chris at adebenham.com (Chris Debenham)
Date: Mon Jun 21 17:46:32 2004
Subject: [Xorg] Xvesa & fluxbox (again)
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Try
/usr/X11R6/bin/Xvesa -screen 1400x1050x16 & (sleep 5; fluxbox)
That will force fluxbox to wait 5 seconds before starting which will
hopefully give X time to start.
Chris
On Mon, Jun 21, 2004 at 04:28:53PM -0800, Asterius Pandoras wrote in a legally b
inding way:
> Date: Mon, 21 Jun 2004 16:28:53 -0800
> From: Asterius Pandoras <[email protected]>
> To: [email protected]
> Subject: [Xorg] Xvesa & fluxbox (again)
>
> When I try to start fluxbox /usr/X11R6/bin/Xvesa -screen 1400x1050x16 &
> fluxbox, it says can't connect to X server. Make sure you start X before
> the Fluxbox. I can run /usr/X11R6/bin/Xvesa -screen 1400x1050x16 & aterm
> though and after I call fluxbox inside of aterm, fluxbox starts just
> fine. How do I start fluxbox on a command line? Any suggestions? Another
> thing is that I'm trying to migrate to ratpoison and, as with fluxbox,
> ratpoison can't connect to X and when I call it from inside of aterm, it
> complains about 7x16bold fonts. Where in general Xserver font path?
> As always, thanks everyone for any suggestions.
>
>
> Asterius.
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
--
From svetljo at gmx.de Tue Jun 22 02:37:59 2004
From: svetljo at gmx.de (Svetoslav Slavtchev)
Date: Tue Jun 22 02:38:32 2004
Subject: [Xorg] Local Multi Users
Message-ID: <[email protected]>
Hi all
Dear Alexandre,
i'm not a X guy, but IMHO there is no such big
difference between X.org and XFree86 in this matter
so if it works with XFree86 it will work with Xorg too
you may want to try the implementation by the linuxconsole project
http://linuxconsole.sourceforge.net
some more pointers & documentation
* initial working implementation based on backport
to linux-2.4 and a lot of documentation
The Backstreet Ruby home page http://startx.times.lv/
* my howto XFree-Local-multi-user-HOWTO
http://tldp.org/HOWTO/XFree-Local-multi-user-HOWTO/index.html
* shorter step by step guide by Jean-Daniel Pauget
http://disjunkt.com/dualhead/
this setup is working for a lot of people
with upto 4 users sofar
if you decide to try it, please keep the
linuxconsole ml posted
and :D
dear Xorg developers,
would it be possible for you to
include the attached patch in Xorg,
so users that want to try multiuser setups
don't need to patch it themselfs
this patch doesn't change X's behaviour when
the new options are not specified
and is currently included in
Debian's XFree86 & Mandrake's Xorg packages
and there are no (related) bug reports
best,
svetljo
PS.
please CC me (and the linuxconsole ml)
as me(we) are not subscribed to the list
PS.2
now subscribed as the ml doesn't allow
posting from unsubcribed users :(
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg-6.7.0-isolate_device.diff
Type: application/octect-stream
Size: 9044 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040622/6b3bb8a1/Xorg-6
.7.0-isolate_device.bin
From brian.paul at tungstengraphics.com Tue Jun 22 10:21:49 2004
From: brian.paul at tungstengraphics.com (Brian Paul)
Date: Tue Jun 22 10:17:18 2004
Subject: [Mesa3d-dev] Re: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alexander Gottwald wrote:
> On Mon, 21 Jun 2004, Keith Whitwell wrote:
>
>
>>Alexander Gottwald wrote:
>>
>>>On Mon, 21 Jun 2004, Keith Whitwell wrote:
>>>
>>>
>>>
>>>>I haven't looked at this change yet, but I'm leery of downstream modificatio
ns
>>>>to extras/Mesa/*. If the change to GL/gl.h is warranted, it should be
>>>>submitted as a patch to Mesa. This is a key file and changes to it are
>>>>closely monitored & must be well understood and justified.
>>>
>>>
>>>
>>>
>>>>As it stands, I believe Mesa builds & runs on windows without modification.
>>>
>>>
>>>This is not a change for win32 but for cygwin. Cygwin by default does not use
>>>stdcall semantics but this is required if we wish to link to the windows open
gl32
>>>library.
>>>
>>>The patch only changes the GLAPIENTRY macro to use __stdcall if USE_OPENGL32
is
>>>defined.
>>>
>>>If it is required, I'll send it as a patch to mesa too.
>>
>>That should be done by changing the definition of GLAPIENTRY - I haven't
>>looked at the change as I said, but it is 500+ lines of differences.
>
>
> This is between 1.1 and 1.2
>
> The actual change is
> $ cvs diff -kk -r 1.1.1.3 -r 1.2 gl.h
> Index: gl.h
> ===================================================================
> RCS file: /cvs/xorg/xc/extras/Mesa/include/GL/gl.h,v
> retrieving revision 1.1.1.3
> retrieving revision 1.2
> diff -u -r1.1.1.3 -r1.2
> --- gl.h 16 Jun 2004 09:16:30 -0000 1.1.1.3
> +++ gl.h 21 Jun 2004 13:35:05 -0000 1.2
> @@ -61,6 +61,9 @@
> # define GLAPI extern
> # endif /* _STATIC_MESA support */
> # define GLAPIENTRY __stdcall
> +#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native windows open
gl32 */
> +# define GLAPI extern
> +# define GLAPIENTRY __stdcall
> #else
> /* non-Windows compilation */
> # define GLAPI extern
>
OK, I've checked this into Mesa CVS.
-Brian
From mcuss at cdlsystems.com Tue Jun 22 10:21:40 2004
From: mcuss at cdlsystems.com (Mark Cuss)
Date: Tue Jun 22 10:24:20 2004
Subject: [Xorg] Using Plasma TVs with X
Message-ID: <176c01c4587d$61ac13c0$ab0e10ac@pinchy>
Hi All
If I'm posting to the wrong spot then please forgive me - I'm a little out
of the loop with regards to the changes in X over the past few months....
I'm wondering if I can hook a plasma TV to a DVI video card (ATI, nVidia)
and run the display through X. I've done some looking and the fancy plasma
displays seem to support a 1280x768 resolution. They also have what they
call an HDMI digital interface, which according to a picture I saw on
Pioneer's web site, looks like it can take two physical forms, one of them
being a DVI looking connector.
So, I'd like to be able to hook one of these displays to my machine and run
it at 1280x768. Does anyone have any tips or experience with doing this?
The Plasma TV is a pretty expensive item for a "buy and try" so I'd like to
get some opinions from the experts.
Thanks in advance!
Mark
Mark Cuss, B. Sc.
Real Time Systems Analyst
System Administrator
CDL Systems Ltd
Suite 230
3553 - 31 Street NW
Calgary, AB, Canada
Phone: 403 289 1733 ext 226
Fax: 403 282 1238
www.cdlsystems.com
From alexdeucher at gmail.com Tue Jun 22 10:39:17 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Tue Jun 22 10:39:21 2004
Subject: [Xorg] Using Plasma TVs with X
In-Reply-To: <176c01c4587d$61ac13c0$ab0e10ac@pinchy>
References: <176c01c4587d$61ac13c0$ab0e10ac@pinchy>
Message-ID: <[email protected]>
On Tue, 22 Jun 2004 11:21:40 -0600, Mark Cuss <[email protected]> wrote:
>
> Hi All
>
> If I'm posting to the wrong spot then please forgive me - I'm a little out
> of the loop with regards to the changes in X over the past few months....
>
> I'm wondering if I can hook a plasma TV to a DVI video card (ATI, nVidia)
> and run the display through X. I've done some looking and the fancy plasma
> displays seem to support a 1280x768 resolution. They also have what they
> call an HDMI digital interface, which according to a picture I saw on
> Pioneer's web site, looks like it can take two physical forms, one of them
> being a DVI looking connector.
>
> So, I'd like to be able to hook one of these displays to my machine and run
> it at 1280x768. Does anyone have any tips or experience with doing this?
> The Plasma TV is a pretty expensive item for a "buy and try" so I'd like to
> get some opinions from the experts.
It should work, however, I've never tried it myself. So I guess my
comment is pretty useless...
Alex
>
> Thanks in advance!
>
> Mark
>
> Mark Cuss, B. Sc.
> Real Time Systems Analyst
> System Administrator
> CDL Systems Ltd
> Suite 230
> 3553 - 31 Street NW
> Calgary, AB, Canada
>
> Phone: 403 289 1733 ext 226
> Fax: 403 282 1238
> www.cdlsystems.com
>
From jonsmirl at yahoo.com Tue Jun 22 11:20:46 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Tue Jun 22 11:20:48 2004
Subject: [Xorg] Using Plasma TVs with X
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I don't think any of the plasma TVs do 1280x768 natively, they do it
with a hardware scaler. You may want to check out the native
resolution of the plasma display first. X will look better if you run
the display at native resolution.
Response time is also important, plasma TVs respond slower than CRTs
amd LCDs. That may have an effect in twitch games.
Plasma's are also designed for being at least five feet away from them
and probably more. If you are going to be closer get a big LCD panel
instead.
Search in google, there are much better places to be asking these
questions. There are a couple of sites dedicated to plasma TVs.
--- Alex Deucher <[email protected]> wrote:
> On Tue, 22 Jun 2004 11:21:40 -0600, Mark Cuss <[email protected]>
> wrote:
> >
> > Hi All
> >
> > If I'm posting to the wrong spot then please forgive me - I'm a
> little out
> > of the loop with regards to the changes in X over the past few
> months....
> >
> > I'm wondering if I can hook a plasma TV to a DVI video card (ATI,
> nVidia)
> > and run the display through X. I've done some looking and the
> fancy plasma
> > displays seem to support a 1280x768 resolution. They also have
> what they
> > call an HDMI digital interface, which according to a picture I saw
> on
> > Pioneer's web site, looks like it can take two physical forms, one
> of them
> > being a DVI looking connector.
> >
> > So, I'd like to be able to hook one of these displays to my machine
> and run
> > it at 1280x768. Does anyone have any tips or experience with doing
> this?
> > The Plasma TV is a pretty expensive item for a "buy and try" so I'd
> like to
> > get some opinions from the experts.
>
> It should work, however, I've never tried it myself. So I guess my
> comment is pretty useless...
>
> Alex
>
> >
> > Thanks in advance!
> >
> > Mark
> >
> > Mark Cuss, B. Sc.
> > Real Time Systems Analyst
> > System Administrator
> > CDL Systems Ltd
> > Suite 230
> > 3553 - 31 Street NW
> > Calgary, AB, Canada
> >
> > Phone: 403 289 1733 ext 226
> > Fax: 403 282 1238
> > www.cdlsystems.com
> >
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
From miffe-miffe at telia.com Tue Jun 22 13:31:05 2004
From: miffe-miffe at telia.com (Mikael Eriksson)
Date: Tue Jun 22 11:31:17 2004
Subject: [Xorg] Xvesa & fluxbox (again)
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
run: xinit /path/to/fluxbox -- /usr/X11R6/bin/Xvesa -screen 1400x1050x16
Asterius Pandoras wrote:
> When I try to start fluxbox /usr/X11R6/bin/Xvesa -screen 1400x1050x16 &
> fluxbox, it says can't connect to X server. Make sure you start X before
> the Fluxbox. I can run /usr/X11R6/bin/Xvesa -screen 1400x1050x16 & aterm
> though and after I call fluxbox inside of aterm, fluxbox starts just
> fine. How do I start fluxbox on a command line? Any suggestions? Another
> thing is that I'm trying to migrate to ratpoison and, as with fluxbox,
> ratpoison can't connect to X and when I call it from inside of aterm, it
> complains about 7x16bold fonts. Where in general Xserver font path?
> As always, thanks everyone for any suggestions.
>
>
> Asterius.
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
From mcuss at cdlsystems.com Tue Jun 22 11:44:45 2004
From: mcuss at cdlsystems.com (Mark Cuss)
Date: Tue Jun 22 11:47:32 2004
Subject: [Xorg] Using Plasma TVs with X
References: <[email protected]>
Message-ID: <17ad01c45888$fd31ea80$ab0e10ac@pinchy>
Thanks
I know a plasma screen doesn't look very good up close - the plan was to use
this for a presentation instead of a projector - having the wider aspect
ration is definitely a nice to have.
I've done a little googling and it seems like this should work. I'll just
make sure the store has a good return policy ;)
Thanks
Mark
----- Original Message -----
From: "Jon Smirl" <[email protected]>
To: "Alex Deucher" <[email protected]>; <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, June 22, 2004 12:20 PM
Subject: Re: [Xorg] Using Plasma TVs with X
> I don't think any of the plasma TVs do 1280x768 natively, they do it
> with a hardware scaler. You may want to check out the native
> resolution of the plasma display first. X will look better if you run
> the display at native resolution.
>
> Response time is also important, plasma TVs respond slower than CRTs
> amd LCDs. That may have an effect in twitch games.
>
> Plasma's are also designed for being at least five feet away from them
> and probably more. If you are going to be closer get a big LCD panel
> instead.
>
> Search in google, there are much better places to be asking these
> questions. There are a couple of sites dedicated to plasma TVs.
>
>
> --- Alex Deucher <[email protected]> wrote:
> > On Tue, 22 Jun 2004 11:21:40 -0600, Mark Cuss <[email protected]>
> > wrote:
> > >
> > > Hi All
> > >
> > > If I'm posting to the wrong spot then please forgive me - I'm a
> > little out
> > > of the loop with regards to the changes in X over the past few
> > months....
> > >
> > > I'm wondering if I can hook a plasma TV to a DVI video card (ATI,
> > nVidia)
> > > and run the display through X. I've done some looking and the
> > fancy plasma
> > > displays seem to support a 1280x768 resolution. They also have
> > what they
> > > call an HDMI digital interface, which according to a picture I saw
> > on
> > > Pioneer's web site, looks like it can take two physical forms, one
> > of them
> > > being a DVI looking connector.
> > >
> > > So, I'd like to be able to hook one of these displays to my machine
> > and run
> > > it at 1280x768. Does anyone have any tips or experience with doing
> > this?
> > > The Plasma TV is a pretty expensive item for a "buy and try" so I'd
> > like to
> > > get some opinions from the experts.
> >
> > It should work, however, I've never tried it myself. So I guess my
> > comment is pretty useless...
> >
> > Alex
> >
> > >
> > > Thanks in advance!
> > >
> > > Mark
> > >
> > > Mark Cuss, B. Sc.
> > > Real Time Systems Analyst
> > > System Administrator
> > > CDL Systems Ltd
> > > Suite 230
> > > 3553 - 31 Street NW
> > > Calgary, AB, Canada
> > >
> > > Phone: 403 289 1733 ext 226
> > > Fax: 403 282 1238
> > > www.cdlsystems.com
> > >
> >
> > _______________________________________________
> > xorg mailing list
> > [email protected]
> > http://freedesktop.org/mailman/listinfo/xorg
> >
>
>
> =====
> Jon Smirl
> [email protected]
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
>
From alexander.gottwald at s1999.tu-chemnitz.de Tue Jun 22 12:03:29 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Tue Jun 22 12:03:34 2004
Subject: [Mesa3d-dev] Re: [Xorg] [Fwd: Re: CVS Update: xc (branch: trunk)]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tue, 22 Jun 2004, Brian Paul wrote:
> > The actual change is
> > $ cvs diff -kk -r 1.1.1.3 -r 1.2 gl.h
> > Index: gl.h
> > ===================================================================
> > RCS file: /cvs/xorg/xc/extras/Mesa/include/GL/gl.h,v
> > retrieving revision 1.1.1.3
> > retrieving revision 1.2
> > diff -u -r1.1.1.3 -r1.2
> > --- gl.h 16 Jun 2004 09:16:30 -0000 1.1.1.3
> > +++ gl.h 21 Jun 2004 13:35:05 -0000 1.2
> > @@ -61,6 +61,9 @@
> > # define GLAPI extern
> > # endif /* _STATIC_MESA support */
> > # define GLAPIENTRY __stdcall
> > +#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native windows op
engl32 */
> > +# define GLAPI extern
> > +# define GLAPIENTRY __stdcall
> > #else
> > /* non-Windows compilation */
> > # define GLAPI extern
> >
>
> OK, I've checked this into Mesa CVS.
Thanks.
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From mark at hymers.org.uk Tue Jun 22 12:24:37 2004
From: mark at hymers.org.uk (Mark Hymers)
Date: Tue Jun 22 12:24:22 2004
Subject: [Xorg] [PATCHES][xlibs] .cvsignore patches
Message-ID: <[email protected]>
Attached are various .cvsignore patches for the following modules of
xlibs:
PanoramiXExt
Xt
X11
xkbfile
Xtst
Mark
--
Mark Hymers <mark at hymers dot org dot uk>
"The relationship between journalists and politicians has often been likened
to that between a dog and a lamp post, although I have never worked out who
is supposed to be which."
Nick Assinder, BBC Online Political Correspondent
-------------- next part --------------
Index: .cvsignore
===================================================================
RCS file: .cvsignore
diff -N .cvsignore
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ .cvsignore 22 Jun 2004 19:02:24 -0000
@@ -0,0 +1,13 @@
+Makefile
+Makefile.in
+aclocal.m4
+autom4te.cache
+config.guess
+config.log
+config.status
+config.sub
+configure
+install-sh
+missing
+mkinstalldirs
+panoramixext.pc
-------------- next part --------------
Index: .cvsignore
===================================================================
RCS file: /cvs/xlibs/Xt/.cvsignore,v
retrieving revision 3.1
diff -u -p -r3.1 .cvsignore
--- .cvsignore 2 Dec 2003 22:38:25 -0000 3.1
+++ .cvsignore 22 Jun 2004 19:17:14 -0000
@@ -23,5 +23,5 @@ libtool
ltmain.sh
missing
mkinstalldirs
-stamp-h1
+stamp-h*
xt.pc
-------------- next part --------------
Index: nls/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/.cvsignore,v
retrieving revision 1.2
diff -u -p -r1.2 .cvsignore
--- nls/.cvsignore 24 Dec 2003 12:19:54 -0000 1.2
+++ nls/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,4 @@
Makefile
Makefile.in
+XLC_LOCALE
+locale.alias
Index: nls/C/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/C/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/C/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/C/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/armscii-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/armscii-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/armscii-8/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/armscii-8/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/en_US.UTF-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/en_US.UTF-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/en_US.UTF-8/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/en_US.UTF-8/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/georgian-academy/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/georgian-academy/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/georgian-academy/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/georgian-academy/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/georgian-ps/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/georgian-ps/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/georgian-ps/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/georgian-ps/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ibm-cp1133/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ibm-cp1133/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ibm-cp1133/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/ibm-cp1133/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iscii-dev/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iscii-dev/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iscii-dev/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iscii-dev/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/isiri-3342/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/isiri-3342/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/isiri-3342/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/isiri-3342/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-1/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-1/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-1/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iso8859-1/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-10/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-10/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-10/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iso8859-10/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-11/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-11/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-11/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iso8859-11/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-13/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-13/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-13/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iso8859-13/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-14/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-14/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-14/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iso8859-14/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-15/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-15/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-15/.cvsignore 15 Jan 2004 10:28:49 -0000 1.1
+++ nls/iso8859-15/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-2/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-2/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-2/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-2/.cvsignore 22 Jun 2004 19:15:56 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-3/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-3/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-3/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-3/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-4/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-4/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-4/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-4/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-5/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-5/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-5/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-5/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-6/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-6/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-6/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-6/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-7/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-7/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-7/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-7/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-8/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-8/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-9/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-9/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-9/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-9/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/iso8859-9e/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/iso8859-9e/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/iso8859-9e/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/iso8859-9e/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ja/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ja/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ja/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ja/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ja.JIS/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ja.JIS/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ja.JIS/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ja.JIS/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ja.S90/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ja.S90/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ja.S90/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ja.S90/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ja.SJIS/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ja.SJIS/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ja.SJIS/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ja.SJIS/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ja.U90/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ja.U90/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ja.U90/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ja.U90/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ja_JP.UTF-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ja_JP.UTF-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ja_JP.UTF-8/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ja_JP.UTF-8/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ko/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ko/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ko/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ko/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/ko_KR.UTF-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/ko_KR.UTF-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/ko_KR.UTF-8/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/ko_KR.UTF-8/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/koi8-c/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/koi8-c/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/koi8-c/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/koi8-c/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/koi8-r/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/koi8-r/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/koi8-r/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/koi8-r/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/koi8-u/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/koi8-u/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/koi8-u/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/koi8-u/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/microsoft-cp1251/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/microsoft-cp1251/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/microsoft-cp1251/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/microsoft-cp1251/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/microsoft-cp1255/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/microsoft-cp1255/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/microsoft-cp1255/.cvsignore 15 Jan 2004 10:28:50 -0000 1.1
+++ nls/microsoft-cp1255/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/microsoft-cp1256/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/microsoft-cp1256/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/microsoft-cp1256/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/microsoft-cp1256/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/mulelao-1/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/mulelao-1/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/mulelao-1/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/mulelao-1/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/nokhchi-1/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/nokhchi-1/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/nokhchi-1/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/nokhchi-1/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/tatar-cyr/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/tatar-cyr/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/tatar-cyr/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/tatar-cyr/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/th_TH/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/th_TH/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/th_TH/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/th_TH/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/th_TH.UTF-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/th_TH.UTF-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/th_TH.UTF-8/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/th_TH.UTF-8/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/tscii-0/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/tscii-0/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/tscii-0/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/tscii-0/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/vi_VN.tcvn/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/vi_VN.tcvn/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/vi_VN.tcvn/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/vi_VN.tcvn/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/vi_VN.viscii/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/vi_VN.viscii/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/vi_VN.viscii/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/vi_VN.viscii/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_CN/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_CN/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_CN/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/zh_CN/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_CN.UTF-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_CN.UTF-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_CN.UTF-8/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/zh_CN.UTF-8/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_CN.gbk/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_CN.gbk/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_CN.gbk/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/zh_CN.gbk/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_HK.big5/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_HK.big5/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_HK.big5/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/zh_HK.big5/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_HK.big5hkscs/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_HK.big5hkscs/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_HK.big5hkscs/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/zh_HK.big5hkscs/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_TW/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_TW/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_TW/.cvsignore 15 Jan 2004 10:28:51 -0000 1.1
+++ nls/zh_TW/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_TW.UTF-8/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_TW.UTF-8/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_TW.UTF-8/.cvsignore 15 Jan 2004 10:28:52 -0000 1.1
+++ nls/zh_TW.UTF-8/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
Index: nls/zh_TW.big5/.cvsignore
===================================================================
RCS file: /cvs/xlibs/X11/nls/zh_TW.big5/.cvsignore,v
retrieving revision 1.1
diff -u -p -r1.1 .cvsignore
--- nls/zh_TW.big5/.cvsignore 15 Jan 2004 10:28:52 -0000 1.1
+++ nls/zh_TW.big5/.cvsignore 22 Jun 2004 19:15:57 -0000
@@ -1,2 +1,3 @@
Makefile
Makefile.in
+XLC_LOCALE
-------------- next part --------------
Index: .cvsignore
===================================================================
RCS file: .cvsignore
diff -N .cvsignore
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ .cvsignore 22 Jun 2004 19:00:22 -0000
@@ -0,0 +1,20 @@
+.deps
+Makefile
+Makefile.in
+aclocal.m4
+autom4te.cache
+config.guess
+config.h
+config.h.in
+config.log
+config.status
+config.sub
+configure
+depcomp
+install-sh
+libtool
+ltmain.sh
+missing
+mkinstalldirs
+stamp-h1
+xkbfile.pc
-------------- next part --------------
Index: .cvsignore
===================================================================
RCS file: .cvsignore
diff -N .cvsignore
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ .cvsignore 22 Jun 2004 19:00:22 -0000
@@ -0,0 +1,27 @@
+.deps
+.libs
+*.lo
+*.la
+Makefile
+Makefile.in
+Shell.h
+StringDefs.c
+StringDefs.h
+aclocal.m4
+autom4te.cache
+compile
+config.guess
+config.h
+config.h.in
+config.log
+config.status
+config.sub
+configure
+depcomp
+install-sh
+libtool
+ltmain.sh
+missing
+mkinstalldirs
+stamp-h*
+xt.pc
From mark at hymers.org.uk Tue Jun 22 12:25:48 2004
From: mark at hymers.org.uk (Mark Hymers)
Date: Tue Jun 22 12:25:30 2004
Subject: [Xorg] [PATCH][xlibs] xkbfile configure.ac fix
Message-ID: <[email protected]>
Attached is a fix for configure.ac for xkbfile. We need to escape the
definition properly for it to work (I discovered this whilst
autoconfing setxkbmap)
Mark
--
Mark Hymers <mark at hymers dot org dot uk>
"++?????++ Out of Cheese Error. Redo From Start."
Interesting Times, Terry Pratchett
-------------- next part --------------
Index: configure.ac
===================================================================
RCS file: /cvs/xlibs/xkbfile/configure.ac,v
retrieving revision 1.1
diff -u -p -u -r1.1 configure.ac
--- configure.ac 18 Apr 2004 10:42:04 -0000 1.1
+++ configure.ac 22 Jun 2004 19:00:22 -0000
@@ -24,7 +24,7 @@ if ! test -d $xkb_base; then
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 mark at hymers.org.uk Tue Jun 22 12:26:52 2004
From: mark at hymers.org.uk (Mark Hymers)
Date: Tue Jun 22 12:26:38 2004
Subject: [Xorg] [PATCH][xlibs] Xtst configure.ac fix
Message-ID: <[email protected]>
Attached is a fix for Xtst which removes a line from configure.ac which
prevents compilation. Having grepped for the symbol which this is
looking for, it appears nowhere in the Xtst source and compiles fine
without this test....
Mark
--
Mark Hymers <mark at hymers dot org dot uk>
"Well, the thing about a black hole - it's main distinguishing feature - is
it's black. And the thing about space, your basic space colour is black. So
how are you supposed to see them?"
Holly, Red Dwarf Series III - Marooned
-------------- next part --------------
? .cvsignore
Index: configure.ac
===================================================================
RCS file: /cvs/xlibs/Xtst/configure.ac,v
retrieving revision 1.4
diff -u -p -r1.4 configure.ac
--- configure.ac 12 Apr 2004 14:51:01 -0000 1.4
+++ configure.ac 22 Jun 2004 19:17:56 -0000
@@ -15,10 +15,6 @@ PKG_CHECK_MODULES(X, x11 xext,
[x_found_with_pkgconfig=yes],
[x_found_with_pkgconfig=no])

-PKG_CHECK_MODULES(RECORDEXT, recordext)
-
-X_CFLAGS="$X_CFLAGS $RECORDEXT_CFLAGS"
-
AC_SUBST(X_CFLAGS)
AC_SUBST(X_LIBS)

From thomas at winischhofer.net Tue Jun 22 17:37:13 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Tue Jun 22 17:38:07 2004
Subject: [Xorg] Using Plasma TVs with X
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
[Argh... I should *really* get used to that "Reply All" thing...]
Jon Smirl wrote:
> I don't think any of the plasma TVs do 1280x768 natively, they do it
> with a hardware scaler.
Starting at 60", they do. Below they are usually 848x480 or 856x480. And
these smaller ones usually support 1360x768 instead of 1280x768.
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
From thomas at winischhofer.net Tue Jun 22 17:41:29 2004
From: thomas at winischhofer.net (Thomas Winischhofer)
Date: Tue Jun 22 17:42:08 2004
Subject: [Xorg] Using Plasma TVs with X
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Jon Smirl wrote:
> --- Thomas Winischhofer <[email protected]> wrote:
>
>>Jon Smirl wrote:
>>
>>>I don't think any of the plasma TVs do 1280x768 natively, they do
>>
>>it
>>
>>>with a hardware scaler.
>>
>>Starting at 60", they do. Below they are usually 848x480 or 856x480.
>
>
> $10K+ - way out of my budget, I hadn't looked at ones that big. That a
> lot of money for something with a 5 year expected life before an
> important pixel dies.
I never said it's a bargain ;) (I got mine for free... happy me... for
watching movies these thingies do quite fine)
Thomas
--
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
From asterius at airpost.net Tue Jun 22 19:19:06 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Tue Jun 22 19:19:09 2004
Subject: [Xorg] Kdrive saga
Message-ID: <[email protected]>
I have built Kdrive against 4.3.0 sources with the following host.def
file I have created:
#define KDriveXServer YES
#define TinyXServer YES
#define XvesaServer YES
#define ProjectRoot /usr/X11R6
#define BuildLBX YES
#define BuildDBE YES
#define KdriveServerExtraDefines -DPIXPRIV
#define BuildRandR YES
#define BuildXInputLib YES
#define Freetype2Dir $(TOP)/extras/freetype2
#define Freetype2LibDir $(TOP)/exports/lib
#define BuildXTrueType YES
#define BuildScreenSaverExt YES
#define BuildScreenSaverLibrary YES
#define SharedLibXss YES
#define ServerXdmcpDefines
Then I " make World", "make install". It's "sorta" working, but not
really. First thing I have noticed that it has shared library compiled
in /usr/X11R6/lib instead of where other GUI applications are looking
for them, in /usr/lib. I have copied by hand those libs and Sylpheed and
couple of others worked. Is there anyway to tell Kdrive to install them
in /usr/lib, or is that safe to copy them their in a bunch? I think
I can symlink them, but not sure of the right way of doing so.
Another thing, and most important for now is the problem with fonts.
On a /usr/X11R6/bin/Xvesa start-up , I have the following errors:
Could not init font path element:
/usr/X11R6/lib/X11/fonts/misc
/usr/X11R6/lib/X11/fonts/75dpi
/usr/X11R6/lib/X11/fonts/100dpi
I have checked those pathes and indeed, I simply don't have those /fonts
directory. I have looked into /usr/X11R6/include directory and found
/fonts there ( not /misc, /75dpi. /100dpi directories, but freetype2).
My aterm complains about "can't load font "7x14". Ratpoison WM can't
start because of "Can't load font 9x15bold.
So, any ideas where is my fonts? I have also looked in kdrive.cf
and found their the following line:
#define DefaultFontPath built-ins
$(FONTDIR)/misc/,$(FONTDIR)/75dpi,$(FONTDIR)/100dpi.
It seems that this kdrive.cf is also readable together with my host.def.
Anyway, any help to recover my fonts is much appreciated. Thanks.
Asterius.
From seb at hypercubesystems.co.uk Wed Jun 23 08:25:25 2004
From: seb at hypercubesystems.co.uk (Seb James)
Date: Wed Jun 23 08:17:09 2004
Subject: [Xorg] -query option missing from Xorg
Message-ID: <[email protected]>
Hi,
I'm building Xorg to run on a small computer, which is an i586, using
uclibc and a late 2.4.x kernel.
I've got a cross-compiled Xorg built ok, but the Xorg binary has no
"-query" option to allow it to send out an Xdmcp query.
However, xdmcp.o is compiled:
-------------------------------------------------------
/data/projects/buildroot.X2/build_i586/staging_dir/bin/i686-linux-uclibc-gcc -c
-O2 -ansi -pedantic -Wall -Wpointer-arith -Wundef -I. -I../include -I../../.
./exports/include/X11 -I../../../include/extensions -I../../../pro
grams/Xserver/Xext -I../../../include/fonts -I../../../programs/Xserver/render
-I../../../lib/Xau -I../lbx -I../../.. -I../../../exports/include -I/usr/X11R
6/include -Dlinux -D_POSIX_SOURCE -D_BSD_SOURCE -D
_GNU_SOURCE -DX_LOCALE -DSHAPE -DXINPUT -DXKB -DXAPPGROUP -DXCSECURITY -DT
OGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DRANDR -DGCCU
SESGAS -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) + 0)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DXSER
V_t -DTRANS_SERVER -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DIPv6
-DDDXOSINIT -DSERVER_LOCK -DDDXOSFATALERROR
-DDDXOSVERRORF -DDDXTIME -DUSE_RGB_TXT -DXV
ENDORNAME='"The X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' xdmcp.c
-------------------------------------------------------
And then the Xdmcp library seems to be linked into Xorg:
-------------------------------------------------------
/data/projects/buildroot.X2/build_i586/staging_dir/bin/i686-linux-uclibc-gcc -o
Xorg -O2 -ansi -pedantic -Wall -Wpointer-arith -Wundef -L../../exports/lib
-L/usr/X11R6/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/Xser
ver/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
../../programs/Xserver/hw/xfree86/common/libxf86.a Xext/libe
xts.a xkb/libxkb.a Xi/libxinput.a randr/librandr.a render/li
brender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a
randr/librandr.a render/librender.a ../../programs/Xserver
/hw/xfree86/os-support/libxf86_os.a -lz -lm -lXau -lXdmc
p -rdynamic -ldl
-------------------------------------------------------
And yet no -query option to the resultant Xorg.
My host.def contains defines to build libXdmcp as a shared library:
-------------------------------------------------------
#define XawI18nDefines -DUSE_XWCHAR_STRING -DUSE_XMBTOWC
/* Could maybe play with this parameter */
#define ThreadedX NO
#define BuildDocs NO
/* Not sure what these are, so won't interfere with xorg defaults */
/* #define KDriveXServer YES */
/* #define KdriveServerExtraDefines -DITSY -DMAXSCREENS=1 */
/* Don't want a TinyX server, want the full shebang */
#define TinyXServer NO
/* we _are_ cross compiling */
#define CrossCompiling YES
/* don't know what this is */
/* #define ItsyCompilerBug YES */
/* what's RandR? */
#undef BuildRandR
#define BuildRandR YES
/* lbx is for reducing X related bandwidth */
#define BuildLBX NO
#define BuildXInputLib YES
#define ProjectRoot /usr/X11R6
#define Freetype2Dir $(TOP)/extras/freetype2
#define Freetype2LibDir $(TOP)/exports/lib
/* X11.tmpl suggests that these are necessary: */
#define BuildFreetype2Library YES
#define HasExpat NO
#define BuildExpatLibrary YES
#define UseExpat YES
#define UseFreetype2 YES
#define UseFontconfig YES
#define BuildFreetype YES
#define BuildFreetype2 YES
#define BuildXftLibrary YES
#define BuildXft1Library YES
#define TermcapLibrary -lncurses
#define BuildXdmcpLib YES
#define SharedLibXdmcp YES
#define BuildXcursorgen NO
#define BuildXTrueType YES
#define BuildScreenSaverExt YES
#define BuildScreenSaverLibrary YES
#define SharedLibXss YES
-------------------------------------------------------
I've tried to compare a standard native build of Xorg on my host, where
the Xorg binary _does_ have the -query option and the Xorg build for my
target, but I can't find the relevant difference.
Can anyone help with any suggestions?
many thanks,
Seb James
From kem at freedesktop.org Wed Jun 23 08:53:24 2004
From: kem at freedesktop.org (Kevin E Martin)
Date: Wed Jun 23 08:53:29 2004
Subject: [Xorg] Adding DMX to X.Org
Message-ID: <[email protected]>
We would like to include DMX in the next X.Org release. I have created
a patch against the head of the current CVS tree with the changes to
existing files as well as a tarball with the newly added files. You can
view these in FreeDesktop.Org Bugzilla #796. Here is the link to the
patch for the existing files:
http://freedesktop.org/bugzilla/attachment.cgi?id=411&action=view
and here is a summary of the changes you will find in this patch:
1. Imakefile and config file changes to build DMX
2. SGI build and config file changes (from SGI)
3. Add DMX support to miinitext.c
4. Allow AbortServer to be called from DMX
5. Add glyph private and picture private support to Render extension
6. Add DMX support to xdpyinfo
7. Add DMX and GLX Proxy support to Xinerama
8. Add support for changing the default VENDOR_RELEASE and VENDOR_STRING
9. Add protocol and structures to support GLX Proxy (from SGI)
If there are no objections to adding DMX, I will check in the changes to
the CVS tree next week.
Note: The patch above does not include the MAXSCREENS changes that we
previously submitted since those changes caused a module ABI change.
When/if the MAXSCREENS changes are accepted, the code in the patch above
will automatically take advantage of it.
For those not familiar with the DMX project, it adds support for
distributing the multihead capabilities of the X Window System across
multiple displays attached to different machines. For example, a simple
application would be to provide multihead support using two desktop
machines, each of which has a single display device attached to it.
This can be scaled up to a large display wall created from multiple
projected displays (up to MAXSCREENS displays). Additional information
on the DMX project can be found on the project web page:
http://dmx.sourceforge.net/
Kevin E. Martin and Rik Faith
From keith at tungstengraphics.com Wed Jun 23 09:05:39 2004
From: keith at tungstengraphics.com (Keith Whitwell)
Date: Wed Jun 23 09:15:24 2004
Subject: [Xorg] Adding DMX to X.Org
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Kevin E Martin wrote:
> We would like to include DMX in the next X.Org release. I have created
> a patch against the head of the current CVS tree with the changes to
> existing files as well as a tarball with the newly added files. You can
> view these in FreeDesktop.Org Bugzilla #796. Here is the link to the
> patch for the existing files:
That's odd -- shouldn't this have been part of the original code fork from
XFree86, or is that just another braino on my part?
Keith
From kem at freedesktop.org Wed Jun 23 10:33:34 2004
From: kem at freedesktop.org (Kevin E Martin)
Date: Wed Jun 23 10:33:39 2004
Subject: [Xorg] Adding DMX to X.Org
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Wed, Jun 23, 2004 at 05:05:39PM +0100, Keith Whitwell wrote:
> Kevin E Martin wrote:
> >We would like to include DMX in the next X.Org release. I have created
> >a patch against the head of the current CVS tree with the changes to
> >existing files as well as a tarball with the newly added files. You can
> >view these in FreeDesktop.Org Bugzilla #796. Here is the link to the
> >patch for the existing files:
>
> That's odd -- shouldn't this have been part of the original code fork from
> XFree86, or is that just another braino on my part?
There were a few patches that we submitted a while back, and they were
checked into XFree86 (and are already part of X.Org), but the main DMX
code base was not merged since we were still actively developing the
current set of features. Now that those features are complete, we're
ready to do the upstream merge.
From krh at bitplanet.net Wed Jun 23 10:36:46 2004
From: krh at bitplanet.net (=?ISO-8859-1?Q?Kristian_H=F8gsberg?=)
Date: Wed Jun 23 10:38:14 2004
Subject: [Xorg] Input device hotplug
Message-ID: <[email protected]>
Hi all,
I've been working on making the X.org server hotplug aware with respect
to input devices. The current situation is that all devices must be
setup in the config file and adding new devices requires config file
editing and server restart. What I've been trying to implement is that
you can plug in an input device while the X server is running and it
will show up as a new XInput device.
The overall design I'm thinking of is to keep the device discovery
mechanism out of the X server. By adding requests to add and remove
devices a client program can monitor hotplug events and tell the server
to add or remove devices accordingly.
I have a prototype running were I've added AddInputDevice() and
RemoveInputDevice() in the XFree86-Misc extension:
typedef struct {
char* name;
char* value;
} XF86MiscDriverOption;
Status XF86MiscAddInputDevice(Display *dpy,
const char *identifier,
const char *driver,
XF86MiscDriverOption *options,
int option_count);
Status XF86MiscRemoveInputDevice(Display *dpy,
const char *identifier);
i.e. the AddInputDevice arguments correspond to the InputDevice section
of the config file. The implementation mimicks the server
initialization sequence; it loads the driver, builds an option list from
the given options, calls PreInit(), and adds the device.
In the prototype I'm using HAL (hal.freedesktop.org) on Linux to
enumerate and discover devices. Other systems could use other
mechanisms, but HAL is intended to be cross platform, and a FreeBSD port
is being discussed right now on the list.
One thing I'ld like to discuss is where to add the add and remove device
interface -- I dont think XFree86-Misc is the right place. My first
approach to this was that the new functionality should be an Xorg
private interface, but I'm thinking that maybe it would be better if it
was a standardized extension to XInput. In that case, is the proposed
interface too Xorg specific?
Comments are welcome. I'm currently trying to get my prototype cleaned
up, and then I'll attach it to a bugzilla entry
Kristian
From jonsmirl at yahoo.com Wed Jun 23 10:47:28 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Wed Jun 23 10:47:31 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On Linux 2.6 you can put an executable in /etc/hotplug.d/input and it
will be run whenever a new device is add/removed. The program/script
could check if xserver is running and tell it about the new device.
This doesn't work for PS/2 devices right now but that is a known
problem and on the queue to be fixed.
--- Kristian_Høgsberg <[email protected]> wrote:
> Hi all,
>
> I've been working on making the X.org server hotplug aware with
> respect
> to input devices. The current situation is that all devices must be
> setup in the config file and adding new devices requires config file
> editing and server restart. What I've been trying to implement is
> that
> you can plug in an input device while the X server is running and it
> will show up as a new XInput device.
>
> The overall design I'm thinking of is to keep the device discovery
> mechanism out of the X server. By adding requests to add and remove
> devices a client program can monitor hotplug events and tell the
> server
> to add or remove devices accordingly.
>
> I have a prototype running were I've added AddInputDevice() and
> RemoveInputDevice() in the XFree86-Misc extension:
>
> typedef struct {
> char* name;
> char* value;
> } XF86MiscDriverOption;
>
> Status XF86MiscAddInputDevice(Display *dpy,
> const char *identifier,
> const char *driver,
> XF86MiscDriverOption *options,
> int option_count);
>
> Status XF86MiscRemoveInputDevice(Display *dpy,
> const char *identifier);
>
> i.e. the AddInputDevice arguments correspond to the InputDevice
> section
> of the config file. The implementation mimicks the server
> initialization sequence; it loads the driver, builds an option list
> from
> the given options, calls PreInit(), and adds the device.
>
> In the prototype I'm using HAL (hal.freedesktop.org) on Linux to
> enumerate and discover devices. Other systems could use other
> mechanisms, but HAL is intended to be cross platform, and a FreeBSD
> port
> is being discussed right now on the list.
>
> One thing I'ld like to discuss is where to add the add and remove
> device
> interface -- I dont think XFree86-Misc is the right place. My first
> approach to this was that the new functionality should be an Xorg
> private interface, but I'm thinking that maybe it would be better if
> it
> was a standardized extension to XInput. In that case, is the
> proposed
> interface too Xorg specific?
>
> Comments are welcome. I'm currently trying to get my prototype
> cleaned
> up, and then I'll attach it to a bugzilla entry
>
> Kristian
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
From krh at bitplanet.net Wed Jun 23 11:20:41 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Wed Jun 23 11:22:12 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Jon Smirl wrote:
> On Linux 2.6 you can put an executable in /etc/hotplug.d/input and it
> will be run whenever a new device is add/removed. The program/script
> could check if xserver is running and tell it about the new device.
Yeah, that's a more lean solution, but HAL has some nice features I
think could be useful: you can attach persistent, per-user properties to
HAL devices, for example, if you want X to ignore a device, you could
set xorg.ignore=true.
Another nice feature is device info files (.fdi files), which is a way
to add properties to a device that match certain criteria. For example,
if a device has usb.vendor="wacom", the fdi-file could add a
xorg.driver="wacom" property.
The daemon that listen to HAL events would use these properties to avoid
adding devices the user wants to ignore and load the right driver for
wacom tablets etc.
In any case, whatever the device discovery mechanism is, it needs some
way to inform the X server of the new input device, which what my post
was about.
> This doesn't work for PS/2 devices right now but that is a known
> problem and on the queue to be fixed.
That's interesting, how is that done? Is there an interrupt when PS/2
devices are plugged in or is it solved by polling?
Kristian
>
> --- Kristian_H?gsberg <[email protected]> wrote:
>
>>Hi all,
>>
>>I've been working on making the X.org server hotplug aware with
>>respect
>>to input devices. The current situation is that all devices must be
>>setup in the config file and adding new devices requires config file
>>editing and server restart. What I've been trying to implement is
>>that
>>you can plug in an input device while the X server is running and it
>>will show up as a new XInput device.
>>
>>The overall design I'm thinking of is to keep the device discovery
>>mechanism out of the X server. By adding requests to add and remove
>>devices a client program can monitor hotplug events and tell the
>>server
>>to add or remove devices accordingly.
>>
>>I have a prototype running were I've added AddInputDevice() and
>>RemoveInputDevice() in the XFree86-Misc extension:
>>
>> typedef struct {
>> char* name;
>> char* value;
>> } XF86MiscDriverOption;
>>
>> Status XF86MiscAddInputDevice(Display *dpy,
>> const char *identifier,
>> const char *driver,
>> XF86MiscDriverOption *options,
>> int option_count);
>>
>> Status XF86MiscRemoveInputDevice(Display *dpy,
>> const char *identifier);
>>
>>i.e. the AddInputDevice arguments correspond to the InputDevice
>>section
>>of the config file. The implementation mimicks the server
>>initialization sequence; it loads the driver, builds an option list
>>from
>>the given options, calls PreInit(), and adds the device.
>>
>>In the prototype I'm using HAL (hal.freedesktop.org) on Linux to
>>enumerate and discover devices. Other systems could use other
>>mechanisms, but HAL is intended to be cross platform, and a FreeBSD
>>port
>>is being discussed right now on the list.
>>
>>One thing I'ld like to discuss is where to add the add and remove
>>device
>>interface -- I dont think XFree86-Misc is the right place. My first
>>approach to this was that the new functionality should be an Xorg
>>private interface, but I'm thinking that maybe it would be better if
>>it
>>was a standardized extension to XInput. In that case, is the
>>proposed
>>interface too Xorg specific?
>>
>>Comments are welcome. I'm currently trying to get my prototype
>>cleaned
>>up, and then I'll attach it to a bugzilla entry
>>
>>Kristian
>>
>>
>>_______________________________________________
>>xorg mailing list
>>[email protected]
>>http://freedesktop.org/mailman/listinfo/xorg
>>
>
>
>
> =====
> Jon Smirl
> [email protected]
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail
>
From idr at us.ibm.com Wed Jun 23 11:30:38 2004
From: idr at us.ibm.com (Ian Romanick)
Date: Wed Jun 23 11:31:17 2004
Subject: [Xorg] Re: Adding DMX to XFree86
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Kevin E Martin wrote:
> I think many of us would very much like to have hardware accelerated
> indirect rendering, and from time to time there has been talk of adding
> it to the DRI project. It's actually been on the "to do" list for the
> DRI project from the original design days, but it's a large project and
> there was little interest in funding it back when I was with PI and VA.
> I'm still hopeful that it will eventually happen.
The current thinking is to, essentially, 'rm -rf xc/programs/Xserver/GL'
and re-write it so that libglx.a loads a device-dependent *_dri.so, like
the client-side libGL does. The advantage being that only one driver
binary will be needed per-device. The support and maintainence
advantages should be obvious.
Work has been started on an Xlib based DRI driver (something of a
contradiction in terms, I know) by Adam Jackson. I've started writing
Python scripts to automatically generate GLX protocol handling code (for
both client-side and server-side). We're getting closer to starting the
"real" work, but I need to clear a few things off my plate first.
My goal is to start a branch in the DRI tree in the next few (3 to 4)
months to get this work going.
From kem at freedesktop.org Wed Jun 23 11:40:23 2004
From: kem at freedesktop.org (Kevin E Martin)
Date: Wed Jun 23 11:40:29 2004
Subject: [Xorg] Re: Adding DMX to XFree86
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
On Wed, Jun 23, 2004 at 11:30:38AM -0700, Ian Romanick wrote:
> Kevin E Martin wrote:
>
> >I think many of us would very much like to have hardware accelerated
> >indirect rendering, and from time to time there has been talk of adding
> >it to the DRI project. It's actually been on the "to do" list for the
> >DRI project from the original design days, but it's a large project and
> >there was little interest in funding it back when I was with PI and VA.
> >I'm still hopeful that it will eventually happen.
>
> The current thinking is to, essentially, 'rm -rf xc/programs/Xserver/GL'
> and re-write it so that libglx.a loads a device-dependent *_dri.so, like
> the client-side libGL does. The advantage being that only one driver
> binary will be needed per-device. The support and maintainence
> advantages should be obvious.
Exactly. That was the basic approach we were planning to take at PI.
FYI, there are several papers (from either HP or SGI, IIRC) that give an
overview of various the approaches. I can try to dig up those refs, if
it would be helpful.
> Work has been started on an Xlib based DRI driver (something of a
> contradiction in terms, I know) by Adam Jackson. I've started writing
> Python scripts to automatically generate GLX protocol handling code (for
> both client-side and server-side). We're getting closer to starting the
> "real" work, but I need to clear a few things off my plate first.
>
> My goal is to start a branch in the DRI tree in the next few (3 to 4)
> months to get this work going.
That's excellent! I look forward to seeing this effort get going.
Kevin
From jonsmirl at yahoo.com Wed Jun 23 11:52:12 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Wed Jun 23 11:52:14 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Kristian Høgsberg <[email protected]> wrote:
> Jon Smirl wrote:
> > On Linux 2.6 you can put an executable in /etc/hotplug.d/input and
> it
> > will be run whenever a new device is add/removed. The
> program/script
> > could check if xserver is running and tell it about the new device.
>
> Yeah, that's a more lean solution, but HAL has some nice features I
> think could be useful: you can attach persistent, per-user properties
> to
> HAL devices, for example, if you want X to ignore a device, you could
>
> set xorg.ignore=true.
>
> Another nice feature is device info files (.fdi files), which is a
> way
> to add properties to a device that match certain criteria. For
> example,
> if a device has usb.vendor="wacom", the fdi-file could add a
> xorg.driver="wacom" property.
>
> The daemon that listen to HAL events would use these properties to
> avoid
> adding devices the user wants to ignore and load the right driver for
>
> wacom tablets etc.
You many also need need hotplug features combined with udev. Udev
supports things like getting serial numbers from the device so that
when mouse X is plugged in it always get assigned to the correct X
server if more than one is running. udev also lets you set the owner of
the device to other than root. I believe HAL is implemented on top of
hotplug/udev.
> > This doesn't work for PS/2 devices right now but that is a known
> > problem and on the queue to be fixed.
>
> That's interesting, how is that done? Is there an interrupt when
> PS/2
> devices are plugged in or is it solved by polling?
I don't know how this will work, I reported the problem to the
maintainer and he said he was already working on a solution.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
From elylevy-xserver at cs.huji.ac.il Wed Jun 23 14:02:54 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Jun 23 14:02:58 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
doesn't it require also adding the ability to change configuration on the
fly?
like if I'm adding a new usb mouse and want to map the scroll to something
else?
if it does, wouldn't people want a way to keep the configuration to a
file?
wouldn't that totally change the idea behind xorg.conf and would finally
let people configure those things per user?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 23 Jun 2004, [ISO-8859-1] Kristian H=F8gsberg wrote:
> Hi all,
>
> I've been working on making the X.org server hotplug aware with respect
> to input devices. The current situation is that all devices must be
> setup in the config file and adding new devices requires config file
> editing and server restart. What I've been trying to implement is that
> you can plug in an input device while the X server is running and it
> will show up as a new XInput device.
>
> The overall design I'm thinking of is to keep the device discovery
> mechanism out of the X server. By adding requests to add and remove
> devices a client program can monitor hotplug events and tell the server
> to add or remove devices accordingly.
>
> I have a prototype running were I've added AddInputDevice() and
> RemoveInputDevice() in the XFree86-Misc extension:
>
> typedef struct {
> char*=09name;
> char*=09value;
> } XF86MiscDriverOption;
>
> Status XF86MiscAddInputDevice(Display *dpy,
> const char *identifier,
> const char *driver,
> XF86MiscDriverOption *options,
> int option_count);
>
> Status XF86MiscRemoveInputDevice(Display *dpy,
> const char *identifier);
>
> i.e. the AddInputDevice arguments correspond to the InputDevice section
> of the config file. The implementation mimicks the server
> initialization sequence; it loads the driver, builds an option list from
> the given options, calls PreInit(), and adds the device.
>
> In the prototype I'm using HAL (hal.freedesktop.org) on Linux to
> enumerate and discover devices. Other systems could use other
> mechanisms, but HAL is intended to be cross platform, and a FreeBSD port
> is being discussed right now on the list.
>
> One thing I'ld like to discuss is where to add the add and remove device
> interface -- I dont think XFree86-Misc is the right place. My first
> approach to this was that the new functionality should be an Xorg
> private interface, but I'm thinking that maybe it would be better if it
> was a standardized extension to XInput. In that case, is the proposed
> interface too Xorg specific?
>
> Comments are welcome. I'm currently trying to get my prototype cleaned
> up, and then I'll attach it to a bugzilla entry
>
> Kristian
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From jonsmirl at yahoo.com Wed Jun 23 14:25:43 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Wed Jun 23 14:25:45 2004
Subject: [Xorg] right way to do keymaps
Message-ID: <[email protected]>
I used to have this in my .Xmodmap file to make the numpad keys work in
editors for text selection. Now something has changed in the Redhat
Xorg server such that this doesn't work any more. What is the right way
to make the numpad keys work for text selection?
keycode 79 = KP_Home
keycode 80 = KP_Up
keycode 81 = KP_Prior
keycode 82 = KP_Subtract
keycode 83 = KP_Left
keycode 84 = KP_Begin
keycode 85 = KP_Right
keycode 86 = KP_Add
keycode 87 = KP_End
keycode 88 = KP_Down
keycode 89 = KP_Next
keycode 90 = KP_Insert
keycode 91 = KP_Delete
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
From krh at bitplanet.net Wed Jun 23 17:00:47 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Wed Jun 23 17:02:13 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Ely Levy wrote:
> doesn't it require also adding the ability to change configuration on the
> fly?
> like if I'm adding a new usb mouse and want to map the scroll to something
> else?
That's what the option array is for. You would do something like
XF86MiscDriverOption mouse_options[] = {
{ "ZAxisMapping", "1 2" }
};
XF86MiscAddInputDevice(dpy, "mouse3", "mouse",
mouse_options, ArrayLength(mouse_options));
So you have the same options available as you have in the config file.
> if it does, wouldn't people want a way to keep the configuration to a
> file?
> wouldn't that totally change the idea behind xorg.conf and would finally
> let people configure those things per user?
Yeah, this would also open up for per user settings.
Kristian
> Ely Levy
> System group
> Hebrew University
> Jerusalem Israel
>
>
>
> On Wed, 23 Jun 2004, [ISO-8859-1] Kristian H?gsberg wrote:
>
>
>>Hi all,
>>
>>I've been working on making the X.org server hotplug aware with respect
>>to input devices. The current situation is that all devices must be
>>setup in the config file and adding new devices requires config file
>>editing and server restart. What I've been trying to implement is that
>>you can plug in an input device while the X server is running and it
>>will show up as a new XInput device.
>>
>>The overall design I'm thinking of is to keep the device discovery
>>mechanism out of the X server. By adding requests to add and remove
>>devices a client program can monitor hotplug events and tell the server
>>to add or remove devices accordingly.
>>
>>I have a prototype running were I've added AddInputDevice() and
>>RemoveInputDevice() in the XFree86-Misc extension:
>>
>> typedef struct {
>> char* name;
>> char* value;
>> } XF86MiscDriverOption;
>>
>> Status XF86MiscAddInputDevice(Display *dpy,
>> const char *identifier,
>> const char *driver,
>> XF86MiscDriverOption *options,
>> int option_count);
>>
>> Status XF86MiscRemoveInputDevice(Display *dpy,
>> const char *identifier);
>>
>>i.e. the AddInputDevice arguments correspond to the InputDevice section
>>of the config file. The implementation mimicks the server
>>initialization sequence; it loads the driver, builds an option list from
>>the given options, calls PreInit(), and adds the device.
>>
>>In the prototype I'm using HAL (hal.freedesktop.org) on Linux to
>>enumerate and discover devices. Other systems could use other
>>mechanisms, but HAL is intended to be cross platform, and a FreeBSD port
>>is being discussed right now on the list.
>>
>>One thing I'ld like to discuss is where to add the add and remove device
>>interface -- I dont think XFree86-Misc is the right place. My first
>>approach to this was that the new functionality should be an Xorg
>>private interface, but I'm thinking that maybe it would be better if it
>>was a standardized extension to XInput. In that case, is the proposed
>>interface too Xorg specific?
>>
>>Comments are welcome. I'm currently trying to get my prototype cleaned
>>up, and then I'll attach it to a bugzilla entry
>>
>>Kristian
>>
>>
>>_______________________________________________
>>xorg mailing list
>>[email protected]
>>http://freedesktop.org/mailman/listinfo/xorg
>
>>
>
From maillists at monochromatic.net Wed Jun 23 19:53:58 2004
From: maillists at monochromatic.net (Marc Britten)
Date: Wed Jun 23 19:53:42 2004
Subject: [Xorg] cross compiling XServer (the X11 module)
Message-ID: <[email protected]>
I've been pretty successful doing a crosscompile of XServer, the one
issue I'm running into is in the X11 module after compiling makekeys the
makefile tries to execute it (and of course fails)
../src/util/makekeys <
/home/yugami/projects/AHT/AHT-Distro/bin/include/X11/keysymdef.h >
ks_tables_h
/bin/sh: line 1: ../src/util/makekeys: cannot execute binary file
how big an issue is this? could i just remove the offending Makefile
line and be done with it and run the above command later when I move it
to the target system?
thanks,
Marc Britten
From yernst at ndsisrael.com Thu Jun 24 06:49:11 2004
From: yernst at ndsisrael.com (Ernst, Yehuda)
Date: Thu Jun 24 06:49:53 2004
Subject: [Xorg] video out
Message-ID: <[email protected]>
hello!
I have a computer mini pc tx2 wit chipset Intel 82815 cgc and has video out.
i am trying to see video on the video out but no success i downloaded new drive
rs from Intel site but i see that it is for 2.4.x
will it work on kernel 2.6?
in the drivers file it is has 2 option xfree 4.2 4.3 what do i need to work wit
h fedora 2 ?
thanks
Yehuda
********************************************************************************
***
Information contained in this email message is intended only for use of the indi
vidual or entity named above. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended re
cipient, you are hereby notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this communi
cation in error, please immediately notify the [email protected] and destroy th
e original message.
********************************************************************************
***
From seb at hypercubesystems.co.uk Thu Jun 24 08:22:10 2004
From: seb at hypercubesystems.co.uk (Seb James)
Date: Thu Jun 24 08:22:17 2004
Subject: [Xorg] -query option missing from Xorg
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
The answer to my question is to get the -DXDMCP define into the gcc
command line when compiling the Xserver. I've done this using a brute
force approach of adding it to the standard defines for gcc, as I've not
found the "right way" to do it in host.def/cross.def/xorgsite.def etc.
Seb James.
From keithp at keithp.com Thu Jun 24 18:30:52 2004
From: keithp at keithp.com (Keith Packard)
Date: Thu Jun 24 18:32:01 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: Your message of "Wed, 23 Jun 2004 19:36:46 +0200."
<[email protected]>
Message-ID: <[email protected]>
Around 19 o'clock on Jun 23, =?ISO-8859-1?Q?Kristian_H=F8gsberg?= wrote:
> 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.
> One thing I'ld like to discuss is where to add the add and remove device
> interface
I'd like to think this belongs in the XInput extension. There are other
changes which we can add to that extension at the same time and rev the
protocol version. Coding up backward-compatibility stuff will also be
necessary; take a look at how XFixes manages that (client sends its
version number, X server ensures protocol is compatible with that version).
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040624/e0a92488/attach
ment.pgp
From keithp at keithp.com Thu Jun 24 18:38:27 2004
From: keithp at keithp.com (Keith Packard)
Date: Thu Jun 24 18:39:41 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: Your message of "Thu, 24 Jun 2004 00:02:54 +0300."
<[email protected]>
Message-ID: <[email protected]>
Around 0 o'clock on Jun 24, Ely Levy wrote:
> doesn't it require also adding the ability to change configuration on the
> fly?
I'm thinking adding an XInput device would be straightforward, and what
we'll want to do is let clients find out which physical device(s) are
associated with the core pointer -- every device will be an 'extension'
device and some subset will be mapped to the 'core' pointer. That just
means we'll want to modify things so that clients can both tell which
physical devices are connected to the core pointer and what the union of
those capabilities are.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040624/1e413182/attach
ment.pgp
From asterius at airpost.net Thu Jun 24 18:44:19 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Thu Jun 24 18:44:21 2004
Subject: [Xorg] Kdrive saga
Message-ID: <[email protected]>
Just another try. Hope that someone can clue me in. Thanks.
Asterius.
On Tue, 22 Jun 2004 18:19:06 -0800, "Asterius Pandoras"
<[email protected]> said:
> I have built Kdrive against 4.3.0 sources with the following host.def
> file I have created:
> #define KDriveXServer YES
> #define TinyXServer YES
> #define XvesaServer YES
> #define ProjectRoot /usr/X11R6
> #define BuildLBX YES
> #define BuildDBE YES
> #define KdriveServerExtraDefines -DPIXPRIV
> #define BuildRandR YES
> #define BuildXInputLib YES
> #define Freetype2Dir $(TOP)/extras/freetype2
> #define Freetype2LibDir $(TOP)/exports/lib
> #define BuildXTrueType YES
> #define BuildScreenSaverExt YES
> #define BuildScreenSaverLibrary YES
> #define SharedLibXss YES
> #define ServerXdmcpDefines
>
> Then I " make World", "make install". It's "sorta" working, but not
> really. First thing I have noticed that it has shared library compiled
> in /usr/X11R6/lib instead of where other GUI applications are looking
> for them, in /usr/lib. I have copied by hand those libs and Sylpheed and
> couple of others worked. Is there anyway to tell Kdrive to install them
> in /usr/lib, or is that safe to copy them their in a bunch? I think
> I can symlink them, but not sure of the right way of doing so.
>
> Another thing, and most important for now is the problem with fonts.
> On a /usr/X11R6/bin/Xvesa start-up , I have the following errors:
>
> Could not init font path element:
> /usr/X11R6/lib/X11/fonts/misc
> /usr/X11R6/lib/X11/fonts/75dpi
> /usr/X11R6/lib/X11/fonts/100dpi
>
> I have checked those pathes and indeed, I simply don't have those /fonts
> directory. I have looked into /usr/X11R6/include directory and found
> /fonts there ( not /misc, /75dpi. /100dpi directories, but freetype2).
>
> My aterm complains about "can't load font "7x14". Ratpoison WM can't
> start because of "Can't load font 9x15bold.
>
> So, any ideas where is my fonts? I have also looked in kdrive.cf
> and found their the following line:
> #define DefaultFontPath built-ins
> $(FONTDIR)/misc/,$(FONTDIR)/75dpi,$(FONTDIR)/100dpi.
>
> It seems that this kdrive.cf is also readable together with my host.def.
> Anyway, any help to recover my fonts is much appreciated. Thanks.
>
> Asterius.
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
From keithp at keithp.com Thu Jun 24 18:49:56 2004
From: keithp at keithp.com (Keith Packard)
Date: Thu Jun 24 18:50:59 2004
Subject: [Xorg] Kdrive saga
In-Reply-To: Your message of "Thu, 24 Jun 2004 18:44:19 PDT."
<[email protected]>
Message-ID: <[email protected]>
Around 18 o'clock on Jun 24, "Asterius Pandoras" wrote:
> Just another try. Hope that someone can clue me in. Thanks.
'kdrive' based X servers are really only supported in the 'xserver' CVS
module. Check out http://xserver.freedesktop.org
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040624/dbd407c5/attach
ment.pgp
From carl at personnelware.com Fri Jun 25 03:24:05 2004
From: carl at personnelware.com (Carl Karsten)
Date: Fri Jun 25 04:35:37 2004
Subject: [Xorg] video out
References: <[email protected]>
Message-ID: <15d501c45aa9$22b9a0a0$1e01a8c0@cnt496>
This is the box I have:
http://www.reality.net/BKi810/photos.html
I use this "control" from
http://www.maersk-moller.net/projects/familynet/TV-Out.html
Works with 2.6 and 2.7.
Carl K
----- Original Message -----
From: "Ernst, Yehuda" <[email protected]>
To: <[email protected]>
Sent: Thursday, June 24, 2004 8:49 AM
Subject: [Xorg] video out
> hello!
>
> I have a computer mini pc tx2 wit chipset Intel 82815 cgc and has video out.
> i am trying to see video on the video out but no success i downloaded new
drivers from Intel site but i see that it is for 2.4.x
> will it work on kernel 2.6?
> in the drivers file it is has 2 option xfree 4.2 4.3 what do i need to work
with fedora 2 ?
>
> thanks
>
> Yehuda
>
********************************************************************************
***
> Information contained in this email message is intended only for use of the
individual or entity named above. If the reader of this message is not the
intended recipient, or the employee or agent responsible to deliver it to the
intended recipient, you are hereby notified that any dissemination, distribution
or copying of this communication is strictly prohibited. If you have received
this communication in error, please immediately notify the [email protected]
and destroy the original message.
>
********************************************************************************
***
>
--------------------------------------------------------------------------------
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From carl at personnelware.com Fri Jun 25 04:39:09 2004
From: carl at personnelware.com (Carl Karsten)
Date: Fri Jun 25 04:35:40 2004
Subject: [Xorg] list sugestion: reply to list not sender
Message-ID: <15d601c45aa9$259d3890$1e01a8c0@cnt496>
Quick suggestion to the list admin: set "reply to" to the list addr.
If the current config is deliberate, then nevermind, it isn't that big a deal.
Carl K
http://www.personnelware.com/carl/resume.html
From alexander.gottwald at s1999.tu-chemnitz.de Fri Jun 25 04:36:02 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Fri Jun 25 04:36:15 2004
Subject: [Xorg] Japanese Keyboards
Message-ID: <[email protected]>
Hi
On cygwin we recently noticed problems with the Hiragana_Katakana and the
backslash/underscore key. The keyboard definition assigned these keys to
scancodes 208 and 211 but they were reported as 120 and 123. I've changed
the definition in keycode/xfree86 and would like to import that to the
CVS but I'm not sure if there was a change on linux which required the
definition to 208/211.
Could someone with a japanese keyboard (jp106) running Xorg on linux please
report which keycode xev reports for the Hiragana_Katakana and the backslash/
underscore key. xev has output similar to this
KeyRelease event, serial 27, synthetic NO, window 0x2800001,
root 0x3b, subw 0x2800002, time 2006969830, (23,45), root:(180,145),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 characters: "a"
I'm especially interested in the value of keycode (38 in the example).
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From msipkema at sipkema-digital.com Fri Jun 25 06:06:20 2004
From: msipkema at sipkema-digital.com (Martijn Sipkema)
Date: Fri Jun 25 05:07:02 2004
Subject: [Xorg] list sugestion: reply to list not sender
References: <15d601c45aa9$259d3890$1e01a8c0@cnt496>
Message-ID: <001a01c45ab5$35c9e220$161b14ac@boromir>
I think this is deliberate in that it helps to avoid mail-loops.
--ms
----- Original Message -----
From: "Carl Karsten" <[email protected]>
To: <[email protected]>
Sent: Friday, June 25, 2004 12:39
Subject: [Xorg] list sugestion: reply to list not sender
> Quick suggestion to the list admin: set "reply to" to the list addr.
>
> If the current config is deliberate, then nevermind, it isn't that big a deal.
>
> Carl K
> http://www.personnelware.com/carl/resume.html
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
>
From daniel at freedesktop.org Fri Jun 25 05:13:22 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Fri Jun 25 05:13:25 2004
Subject: [Xorg] list sugestion: reply to list not sender
In-Reply-To: <15d601c45aa9$259d3890$1e01a8c0@cnt496>
References: <15d601c45aa9$259d3890$1e01a8c0@cnt496>
Message-ID: <[email protected]>
On Fri, Jun 25, 2004 at 06:39:09AM -0500, Carl Karsten wrote:
> Quick suggestion to the list admin: set "reply to" to the list addr.
>
> If the current config is deliberate, then nevermind, it isn't that big a deal.
Yah, it's deliberate - google for "reply-to munging considered harmful"
or something.
--
Daniel Stone <[email protected]>
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/20040625/559c0008/attach
ment.pgp
From krh at bitplanet.net Fri Jun 25 06:48:46 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Fri Jun 25 06:50:21 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
Message-ID: <[email protected]>
[ Joe, I'm cc'ing the list, I assume you meant to send to the list too ]
Joe Krahn wrote:
> Kristian H?gsberg wrote:
> ...
>
>> One thing I'ld like to discuss is where to add the add and remove
>> device interface -- I dont think XFree86-Misc is the right place. My
>> first approach to this was that the new functionality should be an
>> Xorg private interface, but I'm thinking that maybe it would be better
>> if it was a standardized extension to XInput. In that case, is the
>> proposed interface too Xorg specific?
>
>
> OK... the big problem is a total lack of XINPUT design docs. (Or at
> least that's how XFree86 was designed. I hope X.org is more interested
> in fixing this.)
Are you talking about the protocol design or the server internal
(implementation) design? Or both?
> Improving XINPUT is definitely the place to do it correctly. I worked on
> this for a while some time ago, then Jim Gettys accepted the task as
> XFree86 XINPUT manager. I knew he could do a much better job than I,
> so I put it off until he had time to get going, but that never happened
> do to his time investment in freedesktop.org and x.org.
>
> First, XINPUT has always had hotplugging ability. If you notice,
> the reference X server implementation has a list of "OffDevices".
> These are devices the server knows about, but are not available.
Yes, I did notice that list, but I think it is important that
hotplugging will work also for devices that wasn't previously
configured. If I buy a new device I should be able to just plug it in
and use it without editing xorg.conf and restarting the server.
> XFree86 should have been designed to allow a configured-but-absent
> driver load, but remain OFF until the driver sees that it has become
> available. The current driver loading scheme has gotten mangled in
> this respect, because XFree86's XINPUT never had a written design
> plan. I think that needs to be done before a release contains
> hotplugging.
The configured-but-absent concept is useful, i.e. I don't want to
configure my spaceball everytime I plug it in. But I'm not sure the
server needs to know about those devices. The overall approach I have
in mind is that the device detection mechanism/daemon is outside the
server, and when an input device is found, this daemon tells the server
to load the appropriate driver and add the device with a given list of
options.
> One big problem in the current design is that the main Control()
> function is not used correctly. Driver loading and unloading should
> never open/close the actual device. That is the job of Control().
> Why is this important? Because a server that is switched away
> from it's VT is told to close and reopen it's devices via Control().
Sounds reasonable, I think one side effect of this problem is that there
now is some confusion about what to do on DEVICE_INIT and what to do on
DEVICE_ON. In the current implementation it doesn't really matter
because all devices are DEVICE_INIT'ed and then immediately DEVICE_OPEN'ed.
Another thing that confused me is PreInit() and DEVICE_INIT... are both
really necessary? Couldn't DEVICE_INIT code be moved to PreInit()?
> Some stuff I wrote up before:
> ---------------------------------------------------------------------
> Control() is intended to be the primary access point to the driver,
> named <device_name>Control. Here are it's functions:
>
> <Name>Control:
> To keep things confusing, this function is pointed to by
> local->device_control, is called "deviceProc" in Xi docs, and is
> NOT related to XDeviceControl (that's the local->control_proc)
>
> This process is to enable/disable/open/close a device.
>
> DEVICE_INIT: Here is where you should make sure the device
> is present and working. If this fails, the driver should
> remain loaded, but the devices stays in the "Device OFF"
> list. OFF devices should get DEVICE_INIT called
> some time later to poll for the devices existence, such
> as just before replying to a ListDevices request.
Again, couldn't this be merged into PreInit()?
> DEVICE_ON: This is the signal to actually open the device.
> If local->flags & XI86_OPEN_ON_INIT, or it
> is a core device, this is called at initialization.
> Otherwise, open when XOpenDevice is first called.
> It is also called when restoring a VT switch.
>
> DEVICE_OFF: Called by XFree86 only when switching to
> another VT. If the device is stateful, be sure to
> save state information to restore when DEVICE_ON is called.
>
> DEVICE_CLOSE: Ideally, this should get called when
> XCloseDevice is called. Current XFree86 keeps all devices
> open at all times.
>
> ---------------------------------------------------------------
>
> Now, back to client commands for device controls:
>
> Client controls should be via XChangeDeviceControl and
> XGetDeviceControl. But, this is the most incomplete command
> in the XINPUT spec. It is not very extensible.
>
> One fix for these is to add more enums for the obviously-missing
> stuff like DEVICE_RESET, and specify a range of enums
> for private device-specific controls.
>
> Or, instead of device-specific enums, just add a few enums
> for generic control commands similar to XClientMessage, that
> can send an ASCII control name, and an ASCII parameter value,
> or char/short/long binary data.
>
> That still does not address the issue server notification for
> loading/unloading a driver. That part is more complicated that
> sending device control parameters, and probably is worth
> adding some new functions to XINPUT, such as XAddInputDevice.
I dont think XChangeDeviceControl is appropriate for adding and removing
devices, since it operates on an pre-existing XDevice. It should also
work if you plug in a device that isn't mentioned in xorg.conf.
Another thing, I think that the options you specify with
XAddInputDevice() should be the same or a subset of those you can change
with the new verion of XChangeDeviceControl(). This way there would be
only one option mechanism to implement. I think the ASCII parameter
name is nice, but I'm not sure the binary data is so useful... ASCII
values should be sufficient I think.
> There are other issues as well: Relative versus absolute events
> are not handled correctly in XFree86. XChangePointerDevice and
> XChangeKeyboardDevice need to be redesigned with the idea of
> simultaneous core devices. etc, etc.
Right, so you basically toggle wether or not to send core events and
drop the idea of a single core pointer?
> Anyone feel up to collaborating on ironing out the XINPUT
> implementation design docs, and potential XINPUT additions??
Yeah, I'm in. I think there are two efforts here: documenting/cleaning
up the XINPUT implementation and extending XINPUT to deal with hotplug
and better device control. We should probably set up a wiki page where
we can flesh out the proposed extensions and modifications to XINPUT.
Kristian
From alexander.gottwald at s1999.tu-chemnitz.de Fri Jun 25 08:15:10 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Fri Jun 25 08:15:13 2004
Subject: [Xorg] hw/xfree86 and XFree86Server
Message-ID: <[email protected]>
Hi
I'm doing some cleanup to the hw/xwin code and stumbled over the
XFree86Server define. Is this an indication that the server uses
the hw/xfree86 ddx or is an indication that the code is from the
xorg (or xfree) repository.
I want a clean identifier that I'm not compiling the hw/xfree86
ddx.
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From jbarnes at sgi.com Fri Jun 25 10:00:56 2004
From: jbarnes at sgi.com (Jesse Barnes)
Date: Fri Jun 25 10:01:54 2004
Subject: [Xorg] Re: Xserver device I/O on Linux
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tuesday, May 4, 2004 1:30 pm, John Dennis wrote:
> Both xfree86 and xorg on which it is based has code for using
> /proc/bus/pci on linux, in fact when building for ia64 this is exactly
> what happens so I'm a bit confused as to why you're having an issue with
> ia64.
ia64 doesn't, by default, build with PCI domain support. It defines
INCLUDE_XF86_NO_DOMAIN which causes it to use /dev/mem for things. I'd like
to change that.
> We've been building and shipping X for ia64 for a while using this
> code base. One change we recently made was to always use the linux
> version of the pci routines on all architectures, it had been the case
> that on x86 the pci code was accessing pci config space via the IO ports
> and soon this won't be supported (pci express does not support it and
> there are issues with concurrency on mp machines). This was a trival one
> line change to an ifdef to use the linux code.
So you removed the INCLUDE_XF86_NO_DOMAIN define?
> I'm not sure what you mean by port I/O and mapping not being provided in
> a way the server expects could you elaborate? A lot of these issues have
> been addressed. But you're certainly right, port I/O on non-x86
> architectures has been a nasty area.
Here's a patch that might illustrate some of what I'm trying to do. There are
several issues at play here:
o Linux/ia64 kernel PCI domain support (I still need to do this properly,
the attached patch is funky because PCIIOC_CONTROLLER isn't implemented
in my kernel)
o bus addr != host addr on some ia64 platforms, so X on ia64 needs to have
pciBusAddrToHostAddr implemented, this should be easy with
the /proc/bus/pci API
o ia64Pci.c roots around in /dev/mem, which can cause MCAs on machines that
don't have the addresses it's looking for, so some other mechanism for
discovering which PCI bridge is present would be desirable
o legacy port access isn't handled gracefully on some platforms, it causes
master aborts. I've got a patch to the Linux/ia64 kernel which will
recover from this condition and send offending apps a SIGBUS when this
occurs, which seems to be working well enough for X to boot cards up
So does anyone own hw/xorg/os-support in the new tree? If not, Shrijeet and I
would be willing to help out...
Thanks,
Jesse
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x-domain-master-abort-3.patch
Type: text/x-diff
Size: 0 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040625/0d3760ca/x-doma
in-master-abort-3.bin
From krahn at niehs.nih.gov Fri Jun 25 14:28:28 2004
From: krahn at niehs.nih.gov (Joe Krahn)
Date: Fri Jun 25 14:29:02 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Kristian H?gsberg wrote:
> [ Joe, I'm cc'ing the list, I assume you meant to send to the list too ]
Ooops; REPLY to lists usually goes to the list email.
>
>> Kristian H?gsberg wrote:
>> ...
>>
>>> One thing I'ld like to discuss is where to add the add and remove
>>> device interface -- I dont think XFree86-Misc is the right place. My
>>> first approach to this was that the new functionality should be an
>>> Xorg private interface, but I'm thinking that maybe it would be
>>> better if it was a standardized extension to XInput. In that case,
>>> is the proposed interface too Xorg specific?
>>
>>
>>
>> OK... the big problem is a total lack of XINPUT design docs. (Or at
>> least that's how XFree86 was designed. I hope X.org is more interested
>> in fixing this.)
>
>
> Are you talking about the protocol design or the server internal
> (implementation) design? Or both?
Both. The XINPUT protocol looks like a somewhat unfinished work, and
was designed aroung the idea of dumb devices. As for XFree86, the XINPUT
server code has gotten mangled due to never having a real design doc.
>
>> Improving XINPUT is definitely the place to do it correctly. I worked on
>> this for a while some time ago, then Jim Gettys accepted the task as
>> XFree86 XINPUT manager. I knew he could do a much better job than I,
>> so I put it off until he had time to get going, but that never happened
>> do to his time investment in freedesktop.org and x.org.
>>
>> First, XINPUT has always had hotplugging ability. If you notice,
>> the reference X server implementation has a list of "OffDevices".
>> These are devices the server knows about, but are not available.
>
>
> Yes, I did notice that list, but I think it is important that
> hotplugging will work also for devices that wasn't previously
> configured. If I buy a new device I should be able to just plug it in
> and use it without editing xorg.conf and restarting the server.
Agreed. I'm just pointing out that X in general is much more hotplug
friendly than XFree86, and I was always annoyed that XFree86 would
ignore a device config if it didn't happen to be available when X started.
>
>> XFree86 should have been designed to allow a configured-but-absent
>> driver load, but remain OFF until the driver sees that it has become
>> available. The current driver loading scheme has gotten mangled in
>> this respect, because XFree86's XINPUT never had a written design
>> plan. I think that needs to be done before a release contains
>> hotplugging.
>
>
> The configured-but-absent concept is useful, i.e. I don't want to
> configure my spaceball everytime I plug it in. But I'm not sure the
> server needs to know about those devices. The overall approach I have
> in mind is that the device detection mechanism/daemon is outside the
> server, and when an input device is found, this daemon tells the server
> to load the appropriate driver and add the device with a given list of
> options.
>
>> One big problem in the current design is that the main Control()
>> function is not used correctly. Driver loading and unloading should
>> never open/close the actual device. That is the job of Control().
>> Why is this important? Because a server that is switched away
>> from it's VT is told to close and reopen it's devices via Control().
>
>
> Sounds reasonable, I think one side effect of this problem is that there
> now is some confusion about what to do on DEVICE_INIT and what to do on
> DEVICE_ON. In the current implementation it doesn't really matter
> because all devices are DEVICE_INIT'ed and then immediately DEVICE_OPEN'ed.
Yes, that's how it is, and that is definitely the wrong thing to do.
>
> Another thing that confused me is PreInit() and DEVICE_INIT... are both
> really necessary? Couldn't DEVICE_INIT code be moved to PreInit()?
In my opinion, most or all PreInit code should be moded to DEVICE_INIT.
In fact, PreInit is probably not needed. It is trying to do what
DEVICE_INIT was always designed to do. PreInit mainly exists because
it was put there for video drivers. IMHO, it would make sense to use the
XINPUT concept for all drivers to have a single Control() function that
is sent DEVICE_INIT, DEVICE_ON, etc.
>
>> Some stuff I wrote up before:
>> ---------------------------------------------------------------------
>> Control() is intended to be the primary access point to the driver,
>> named <device_name>Control. Here are it's functions:
>>
>> <Name>Control:
>> To keep things confusing, this function is pointed to by
>> local->device_control, is called "deviceProc" in Xi docs, and is
>> NOT related to XDeviceControl (that's the local->control_proc)
>>
>> This process is to enable/disable/open/close a device.
>>
>> DEVICE_INIT: Here is where you should make sure the device
>> is present and working. If this fails, the driver should
>> remain loaded, but the devices stays in the "Device OFF"
>> list. OFF devices should get DEVICE_INIT called
>> some time later to poll for the devices existence, such
>> as just before replying to a ListDevices request.
>
>
> Again, couldn't this be merged into PreInit()?
Why not go with the well-defined X method? Why have a PreInit() at all?
>
>> DEVICE_ON: This is the signal to actually open the device.
>> If local->flags & XI86_OPEN_ON_INIT, or it
>> is a core device, this is called at initialization.
>> Otherwise, open when XOpenDevice is first called.
>> It is also called when restoring a VT switch.
>>
>> DEVICE_OFF: Called by XFree86 only when switching to
>> another VT. If the device is stateful, be sure to
>> save state information to restore when DEVICE_ON is called.
>>
>> DEVICE_CLOSE: Ideally, this should get called when
>> XCloseDevice is called. Current XFree86 keeps all devices
>> open at all times.
>>
>> ---------------------------------------------------------------
>>
>> Now, back to client commands for device controls:
>>
>> Client controls should be via XChangeDeviceControl and
>> XGetDeviceControl. But, this is the most incomplete command
>> in the XINPUT spec. It is not very extensible.
>>
>> One fix for these is to add more enums for the obviously-missing
>> stuff like DEVICE_RESET, and specify a range of enums
>> for private device-specific controls.
>>
>> Or, instead of device-specific enums, just add a few enums
>> for generic control commands similar to XClientMessage, that
>> can send an ASCII control name, and an ASCII parameter value,
>> or char/short/long binary data.
>>
>> That still does not address the issue server notification for
>> loading/unloading a driver. That part is more complicated that
>> sending device control parameters, and probably is worth
>> adding some new functions to XINPUT, such as XAddInputDevice.
>
>
> I dont think XChangeDeviceControl is appropriate for adding and removing
> devices, since it operates on an pre-existing XDevice. It should also
> work if you plug in a device that isn't mentioned in xorg.conf.
>
> Another thing, I think that the options you specify with
> XAddInputDevice() should be the same or a subset of those you can change
> with the new verion of XChangeDeviceControl(). This way there would be
> only one option mechanism to implement. I think the ASCII parameter
> name is nice, but I'm not sure the binary data is so useful... ASCII
> values should be sufficient I think.
I think ASCII is good for most things, but I can think of cases where
binary is useful, such as a force feedback, or even program code for a
smart device.
The things I'm thinking of are more like custom device controls, rather
than things you would put into xorg.conf. The problem is that adding a
custom control type means adding an X protocol data description and
modifying the server. So, I'm thinking it would be good to add general
use control types that can handle more than just ASCII.
>
>> There are other issues as well: Relative versus absolute events
>> are not handled correctly in XFree86. XChangePointerDevice and
>> XChangeKeyboardDevice need to be redesigned with the idea of
>> simultaneous core devices. etc, etc.
>
>
> Right, so you basically toggle wether or not to send core events and
> drop the idea of a single core pointer?
>
>> Anyone feel up to collaborating on ironing out the XINPUT
>> implementation design docs, and potential XINPUT additions??
>
>
> Yeah, I'm in. I think there are two efforts here: documenting/cleaning
> up the XINPUT implementation and extending XINPUT to deal with hotplug
> and better device control. We should probably set up a wiki page where
> we can flesh out the proposed extensions and modifications to XINPUT.
Well, I've never gotten involved in wiki, but this is certainly an ideal
case for wiki, since many people will have opinions about the best way
to do it.
How do we start a wiki XINPUT page?
Joe
From asterius at airpost.net Fri Jun 25 17:07:55 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Fri Jun 25 17:08:00 2004
Subject: [Xorg] Troubles building Xserver from CVS
Message-ID: <[email protected]>
I have followed the instructions and have the following after running
"make"
make: Nothing to be done for `all'.
./autoge.sh --prefix=/opt/fdo
autoreconf-2.59: Entering directory `.'
autoreconf-2.59: config.ac: not using Gettext
autoreconf-2.59: running:aclocal --output=aclocal.m4t
autoreconf-2.59: `aclocal.m4' is unchanged
autoreconf-2.59: configure am: not using Libtool
autoreconf-2.59: running: /usr/bin autoconf
autoreconf-2.59: configure.ac: not using Autoheader
autoreconf-2.59: running: automake --add-missing --copy
autoreconf-2.59: leaving directory `.'
checking for a BSD-compatible install /bin/install -c
checking whether build environment is sane --yes
checking for gawk ... gawk
checking whether make sets $(MAKE)...yes
checking whether to enable maintainer-specific portions of Make ---yes
configure: creating ./configure.status
config.status: Creating makefile
conf.status : creating xproto.pc
automake=1.7.9
autoconf=2.59
libtool=1.5
pkg-config 0.15.0
Any ideas? Thanks.
Asterius.
From carl at personnelware.com Fri Jun 25 19:05:58 2004
From: carl at personnelware.com (Carl Karsten)
Date: Fri Jun 25 19:01:44 2004
Subject: [Xorg] Troubles building Xserver from CVS
References: <[email protected]>
Message-ID: <1ab401c45b22$1fe91080$1e01a8c0@cnt496>
> I have followed the instructions and have the following after running
> "make"
> make: Nothing to be done for `all'.
make World
Carl K
From daniel at freedesktop.org Fri Jun 25 21:25:25 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Fri Jun 25 21:25:27 2004
Subject: [Xorg] Troubles building Xserver from CVS
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Fri, Jun 25, 2004 at 05:07:55PM -0700, Asterius Pandoras wrote:
> I have followed the instructions and have the following after running
> "make"
> make: Nothing to be done for `all'.
Try 'make install' to install it; there's really nothing else to do in
Xproto. I recommend jhbuild or similar to install xserver.
--
Daniel Stone <[email protected]>
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/20040626/d825e1ad/attach
ment.pgp
From loc at toya.net.pl Sat Jun 26 08:17:19 2004
From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Sat Jun 26 08:17:25 2004
Subject: [Xorg] Xserver built with --enable-xorgserver
Message-ID: <[email protected]>
#v+
make[1]: Wej?cie do katalogu
`/home/users/jpc/src/Xserver/jhbuild/xserver/xkb'
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../hw/xorg/include
-I../hw/xorg/common -I../hw/xorg/os-support -I../include -I../os
-I../hw/xorg/os-support/bus -I../Xext -I../Xi -I../render -I../randr
-I../xfixes -I../damageext -I../composite -I../mi -I../miext/damage
-I../miext/shadow -I../fb -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/include/X11
-I/opt/fdo/include/X11/Xtrans -I../Xi -I./../mi -I./../hw/xorg/common
-I./../hw/xorg/include -I./../hw/xorg/os-support/bus
-DXKB_DFLT_DISABLED=0 -DXKB_IN_SERVER -DXKB_BASE_DIRECTORY=\"/xkb\"
-DXKB -g -O2 -MT xf86KillSrv.o -MD -MP -MF ".deps/xf86KillSrv.Tpo" -c -o
xf86KillSrv.o xf86KillSrv.c; \
then mv -f ".deps/xf86KillSrv.Tpo" ".deps/xf86KillSrv.Po"; else rm -f
".deps/xf86KillSrv.Tpo"; exit 1; fi
In file included from ./ddxKillSrv.c:41,
from xf86KillSrv.c:2:
../hw/xorg/common/xf86.h:253: error: parse error before "_printf_attribute"
../hw/xorg/common/xf86.h:253: warning: data definition has no type or
storage class
../hw/xorg/common/xf86.h:255: error: parse error before "_printf_attribute"
../hw/xorg/common/xf86.h:255: warning: data definition has no type or
storage class
../hw/xorg/common/xf86.h:257: error: parse error before "_printf_attribute"
../hw/xorg/common/xf86.h:257: warning: data definition has no type or
storage class
../hw/xorg/common/xf86.h:258: error: parse error before "_printf_attribute"
../hw/xorg/common/xf86.h:258: warning: data definition has no type or
storage class
../hw/xorg/common/xf86.h:259: error: parse error before "_printf_attribute"
../hw/xorg/common/xf86.h:259: warning: data definition has no type or
storage class
../hw/xorg/common/xf86.h:260: error: parse error before "_printf_attribute"
../hw/xorg/common/xf86.h:260: warning: data definition has no type or
storage class
#v-
[jpc@loc ~] rpm -q gcc
gcc-3.4.0-4
Any ideas?
btw. Are Xgl and Xsdl supposed to work? What's the status of GLX + DRI?
Is there any sense in GLX without DRI (I found a message which states
that they don't really work together now)?
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Sat Jun 26 09:01:29 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sat Jun 26 09:01:34 2004
Subject: [Xorg] Xserver built with --enable-xorgserver
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sat, Jun 26, 2004 at 05:17:19PM +0200, Jakub Piotr C??apa wrote:
> #v+
> make[1]: Wej??cie do katalogu
> `/home/users/jpc/src/Xserver/jhbuild/xserver/xkb'
> [...]
>
> Any ideas?
Uh, sure - don't do that. xserver/hw/xorg is known broken, and you
should be using debrix (grab debrix, debrix-driver-ati,
debrix-input-keyboard, and debrix-input-mouse; same $CVSROOT) instead.
If you don't have an ATI card, wait until I fix up my CVS setup at home
so I can import some build fixes to make fbdev (and probably nv and
friends) work.
> btw. Are Xgl and Xsdl supposed to work? What's the status of GLX + DRI?
> Is there any sense in GLX without DRI (I found a message which states
> that they don't really work together now)?
Xsdl should work fine.
--
Daniel Stone <[email protected]>
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/20040627/2e9839f6/attach
ment.pgp
From papadako at csd.uoc.gr Sat Jun 26 09:29:56 2004
From: papadako at csd.uoc.gr (Panagiotis Papadakos)
Date: Sat Jun 26 09:30:17 2004
Subject: [Xorg] ATi 3.9.0 drivers with latest X.org CVS problem
Message-ID: <[email protected]>
3D does not work with the latest tree (my previous tree from 23/5 worked
fine). So I guess the problem is related to the dri merge.
I can't find any error in the logs and everything seems to be
initialized just fine. But when I run glxinfo it outputs only
"name of display: :0.0" and it stops there, without exiting to the shell.
Any suggestions?
Regards
Panagiotis Papadakos
From loc at toya.net.pl Sat Jun 26 12:46:16 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Sat Jun 26 12:46:22 2004
Subject: [Xorg] Xserver built with --enable-xorgserver
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Sat, Jun 26, 2004 at 05:17:19PM +0200, Jakub Piotr C??apa wrote:
>
>>#v+
>>make[1]: Wej??cie do katalogu
>>`/home/users/jpc/src/Xserver/jhbuild/xserver/xkb'
>>[...]
>>
>>Any ideas?
>
> Uh, sure - don't do that. xserver/hw/xorg is known broken, and you
> should be using debrix (grab debrix, debrix-driver-ati,
> debrix-input-keyboard, and debrix-input-mouse; same $CVSROOT) instead.
> If you don't have an ATI card, wait until I fix up my CVS setup at home
> so I can import some build fixes to make fbdev (and probably nv and
> friends) work.
Ok. A have a Radeon 9200 so I'll try.
>>btw. Are Xgl and Xsdl supposed to work? What's the status of GLX + DRI?
>>Is there any sense in GLX without DRI (I found a message which states
>>that they don't really work together now)?
>
> Xsdl should work fine.
>
#v+
[jpc@loc ~] /opt/fdo/bin/Xsdl :3
Fatal server error:
no screens found
#v-
(I know it's not really informative, but strace doesn't really look
better. I can provide any info (including playing with gdb), just tell
my what you need.)
--
Ragards,
Jakub Piotr C?apa
From asterius at airpost.net Sat Jun 26 17:29:10 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Sat Jun 26 17:29:14 2004
Subject: [Xorg] Fonts problem
Message-ID: <[email protected]>
As many of you have already know I had many problems and some of them
were answered. Finally, I have successfully built xserver from
CVS ( thanks who replied with "make"), this fixed everything, however,
I still have the same error messages as when I have built Kdrive
against Xfree sources.
Could not init font paths element
/usr/lib/X11/fonts/misc
/usr/lib/X11/fonts/100dpi
/usr/lib/X11/fonts/75dpi
The only difference is that was searhced path was a bit different;
/usr/X11R6/lib/X11/fonts/
Now, I have had posted about this problem on this mailing list and
forums, however I didn't have any response as this problem isn't
existant. It is, some other people have this problem and seraching
the Internet far and wide, I noticed that their pleas are also
unanswered. I can't start some important ( at least for me) apps and
I'm sure that solution is really simple. Please, any one, pointers and
ideas what the hell goes wrong.
Asterius.
From keithp at keithp.com Sat Jun 26 22:17:40 2004
From: keithp at keithp.com (Keith Packard)
Date: Sat Jun 26 22:18:45 2004
Subject: [Xorg] Composite pixmap naming
Message-ID: <[email protected]>
I've added a request to 'name' the backing pixmap (provide a client XID for
the pixmap underlying a redirected window) -- useful when the window gets
unmapped as you can still see the contents. However, by accident, I forgot
to have the XID move to the new pixmap when windows are resized.
At first blush, this seemed like a horrible bug. However, on second
thought it might actually be a feature -- you can continue to paint the
screen from the old window contents until the new contents are all ready,
then delete the old pixmap and paint from the new one.
If the wm and apps would cooperate somehow, I think we could get smooth
resize without any more X server changes.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040626/a5e7ce0c/attach
ment.pgp
From jaymz at artificial-stupidity.net Sat Jun 26 22:30:46 2004
From: jaymz at artificial-stupidity.net (Jaymz Julian)
Date: Sat Jun 26 22:30:55 2004
Subject: [Xorg] Xserver built with --enable-xorgserver
In-Reply-To: <[email protected]>;
from [email protected] on Sat, Jun 26, 2004 at 09:46:16PM +0200
References: <[email protected]> <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sat, Jun 26, 2004 at 09:46:16PM +0200, Jakub Piotr Clapa wrote:
> >>btw. Are Xgl and Xsdl supposed to work? What's the status of GLX + DRI?
> >>Is there any sense in GLX without DRI (I found a message which states
> >>that they don't really work together now)?
> >
> > Xsdl should work fine.
> >
>
> #v+
> [jpc@loc ~] /opt/fdo/bin/Xsdl :3
>
> Fatal server error:
> no screens found
> #v-
You're not actually supposed to use Xsdl - it's a terribly naieve implentation,
which is there just for debugging - but in most cases, the default screen
of 640x480x4 won't work. If you add -screen 640x480x16 or some other value,
then it will work. But you have been warned about the "badly" part. :)
-- jj
--
--
Jaymz Julian - Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people.
Very few people have `I want to be killed and eaten' on their cards,
so Hannibal is out of a job." - http://cards.sf.net
From hagakure962 at adelphia.net Sat Jun 26 23:46:54 2004
From: hagakure962 at adelphia.net (Alex Garcia)
Date: Sat Jun 26 23:47:26 2004
Subject: [Xorg] fatal server error:out of memory
Message-ID: <004c01c45c12$88ebad90$6501a8c0@alex4moz45nqcf>
While trying to run xorgsetup I came up with a blank screen followed by
a series of system beeps. The /var/log/Xorg.0.log showed a lot of info,
pages of it. Towards the end it began to read
WW ***INVALID MEM ALLOCATION*****?(hex left out)?..correcting -followed
by a lot of hex numbers. At the end of the log it comes up Fatal server
error: Out of memory.

Can anyone assist me with correcting this out of memory problem. *hint*
I can?t get more memory for the box, it?s a 486 with 16MB and I?m not
willing to go find ram for it, or spend any money on this old box.
Slackware runs fine with this config, and I assume Xorg would too.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.711 / Virus Database: 467 - Release Date: 6/25/2004

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://freedesktop.org/pipermail/xorg/attachments/20040627/fc049544/attachm
ent.html
From erik_hb_mlist at yahoo.com.au Sun Jun 27 00:47:23 2004
From: erik_hb_mlist at yahoo.com.au (Erik H. Bakke)
Date: Sun Jun 27 00:54:21 2004
Subject: [Xorg] Problems compiling from CVS
Message-ID: <[email protected]>
Hi, just want to report a couple of problems compiling from CVS
The compilation fails when compiling the radeon driver, and complains about
the symbol IEEE_ONE being undeclared.
The system compiling the code is an AMD64 (Opteron) system running Linux
2.6.7, and the compiler is gcc 3.3.3.
Compiler output follows:
rm -f radeon_state_init.o
gcc -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall
-Wpointer-arith -Wundef -I../../../../../../exports/include/X11
-I../../../../../../include/extensions
-I../../../../../../extras/Mesa/src/mesa
-I../../../../../../extras/Mesa/src/mesa/main
-I../../../../../../extras/Mesa/src/mesa/glapi
-I../../../../../../extras/Mesa/src/mesa/shader
-I../../../../../../extras/Mesa/include
-I../../../../../../extras/Mesa/src/mesa/drivers/dri/common
-I../../../../../../extras/Mesa/src/mesa/drivers/dri/radeon
-I../../../../../../lib/GL/dri -I../../../../../../exports/include/X11
-I../../../../../../lib/GL/glx -I../../../../../../lib/
GL/include
-I../../../../../../programs/Xserver/GL/dri
-I../../../../../../programs/Xserver/hw/xfree86/os-support
-I../../../../../../programs/Xserver/hw/xfree86/common
-I../../../../../../extras/drm/shared
-I../../../../../../programs/Xserver/hw/xfree86/drivers/ati
-I../../../../../../lib/GL/dri/drm -I../../../../../..
-I../../../../../../exports/include -Dlinux -D__amd64__
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN
_SOURCE
-D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DFUNCPROTO=15
-DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API
-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING
-DGLX_USE_DLOPEN -DGLX_USE_MESA -D__GLX_ALIGN64
-DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_NEW_INTERFACE -DXVENDORNAME='"The
X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' -fPIC radeon_state_init.c
radeon_state_init.c: In function `radeonInitState':
radeon_state_init.c:544: error: `IEEE_ONE' undeclared (first use in this
function)
radeon_state_init.c:544: error: (Each undeclared identifier is reported only
once
radeon_state_init.c:544: error: for each function it appears in.)
make[6]: *** [radeon_state_init.o] Error 1
make[6]: Leaving directory
`/home/ebakke/cvs/xorg/xc/lib/GL/mesa/drivers/dri/radeon'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/home/ebakke/cvs/xorg/xc/lib/GL/mesa/drivers/dri'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/home/ebakke/cvs/xorg/xc/lib/GL'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/ebakke/cvs/xorg/xc/lib'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/ebakke/cvs/xorg/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/home/ebakke/cvs/xorg/xc'
make: *** [World] Error 2
--
Erik H. Bakke
From sndirsch at suse.de Sun Jun 27 02:00:03 2004
From: sndirsch at suse.de (Stefan Dirsch)
Date: Sun Jun 27 02:02:36 2004
Subject: [Xorg] Problems compiling from CVS
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 27, 2004 at 05:47:23PM +1000, Erik H. Bakke wrote:
> Hi, just want to report a couple of problems compiling from CVS
> The compilation fails when compiling the radeon driver, and complains about
> the symbol IEEE_ONE being undeclared.
>
> The system compiling the code is an AMD64 (Opteron) system running Linux
> 2.6.7, and the compiler is gcc 3.3.3.
--> Bug #805
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
----------------------------------------------------
From martr at zeelandnet.nl Sun Jun 27 05:27:38 2004
From: martr at zeelandnet.nl ([email protected])
Date: Sun Jun 27 05:27:43 2004
Subject: [Xorg] X11R6.7.0 on HP-UX; X Errors.
Message-ID: <[email protected]>
I tried to compile X11R6.7.0 on HP-UX (11.11, PA-RISC2.0, 32-bit)
and more or less succeeded with a few modifications here and there
(only the libraries, not the X server). It was quite an adventure
though. Now when I run some applications (remotely, as I have no
physical access to the machine) sometimes the following message
appears, but the application doesn't crash. I suspect, but it isn't
much more than just a hunch, that it has something to do with xft.
X Error: BadValue (integer parameter out of range for operation) 2
Major opcode: 155
Minor opcode: 4
Resource id: 0x100
Now my question is: how should I interpret this message? How could I
proceed to find out what is where going wrong?
Thanks for any help or hint,
Mart
From loc at toya.net.pl Sun Jun 27 08:18:53 2004
From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Sun Jun 27 08:19:01 2004
Subject: [Xorg] [Patch] debrix
Message-ID: <[email protected]>
I've tried building and running debrix as Daniel suggested but
encountered some problems:
1. debrix-driver-radeon has missing symbols (both radeon and r128)
I've attached a patch to fix this.
2. Now it builds and loads but fails to find any drivers. (adding
atimisc.la to LIBS doesn't help) It also fails to recognize my
chipset on the second BusID. Log file attached.
3. autotoolization of debrix-driver-dummy has not been finished and
some includes lack proper dirs. Patch attached.
Hope that helps. (and hope you will help me with radeon not working).
--
Regards,
Jakub Piotr C?apa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debrix-driver-ati.patch
Type: text/x-patch
Size: 865 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040627/7bc16db0/debrix
-driver-ati-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debrix-driver-dummy.patch
Type: text/x-patch
Size: 2796 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040627/7bc16db0/debrix
-driver-dummy-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debrix.radeon.log
Type: text/x-log
Size: 9648 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040627/7bc16db0/debrix
.radeon-0001.bin
From daniel at freedesktop.org Sun Jun 27 08:23:30 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 27 08:23:32 2004
Subject: [Xorg] [Patch] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 27, 2004 at 05:18:53PM +0200, Jakub Piotr C??apa wrote:
> I've tried building and running debrix as Daniel suggested but
> encountered some problems:
>
> 1. debrix-driver-radeon has missing symbols (both radeon and r128)
> I've attached a patch to fix this.
Cool, this was probably what was needed. Previously, you needed to use
Driver "ati" - does this fix it?
... ah, I already had this uncommitted locally. Really need to get a CVS
tree into my system, so I can commit stuff.
> 2. Now it builds and loads but fails to find any drivers. (adding
> atimisc.la to LIBS doesn't help) It also fails to recognize my
> chipset on the second BusID. Log file attached.
Looks like it's finding the drivers alright. Does Driver "ati" help?
Does it help if you take Load "dri" out?
> 3. autotoolization of debrix-driver-dummy has not been finished and
> some includes lack proper dirs. Patch attached.
Ta, I'll commit this along with the fbdev and nv stuff. Thanks for your
work - much appreciated.
Thanks a lot!
:) d
--
Daniel Stone <[email protected]>
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/20040628/27fba749/attach
ment.pgp
From daniel at freedesktop.org Sun Jun 27 09:46:23 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 27 09:46:43 2004
Subject: [Xorg] [Patch] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 27, 2004 at 06:27:01PM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >On Sun, Jun 27, 2004 at 05:18:53PM +0200, Jakub Piotr C??apa wrote:
> >>I've tried building and running debrix as Daniel suggested but
> >>encountered some problems:
> >>
> >>1. debrix-driver-radeon has missing symbols (both radeon and r128)
> >> I've attached a patch to fix this.
> >
> >Cool, this was probably what was needed. Previously, you needed to use
> >Driver "ati" - does this fix it?
> >
> >... ah, I already had this uncommitted locally. Really need to get a CVS
> >tree into my system, so I can commit stuff.
>
> You really should start using CVS. :D
I had it all done at home, and tarballs uploaded (uploading 5MB sucks
over a modem), so I scp'ed a diff, and imported to CVS from there (which
was painful, because it came from X.Org, and had to be updated from
XORG-RELEASE-1 and XDAMAGE-FIXES along the way, as well as some stuff
from xserver).
So, I had no CVS checkout. I swore I had one around somewhere, but no,
couldn't find one. I'll grab it tonight.
> >>2. Now it builds and loads but fails to find any drivers. (adding
> >> atimisc.la to LIBS doesn't help) It also fails to recognize my
> >> chipset on the second BusID. Log file attached.
> >
> >
> >Looks like it's finding the drivers alright. Does Driver "ati" help?
> >Does it help if you take Load "dri" out?
>
> It was that simple! :D Of course the symbol problems disapear when i
> don't try to use radeon directly. ;-)
> Could we somehow ban this and print a BIG warning when sb. tries to load
> sth strange as a display driver?
I've been thinking about it, yes.
> Problems:
> 1. gnome-terminal draws all text in the upper left-hand corner of the
> screen (xterm works fine). There are also some minor glitches in
> xfwm4 window decorations. xfdesktop4 doesn't draw the background.
> Maybe the reason is that all programs are built with X.org libs, not
> xlibs from fdo.
Interesting - maybe conflicting Xrender versions. Does rebuilding help?
Sorry to be a pain in the butt ...
> 2. The server fails to restore the text mode (i get a blank screen
> instead).
Weird. That shouldn't happen - works for me on a Radeon 9000.
> >>3. autotoolization of debrix-driver-dummy has not been finished and
> >> some includes lack proper dirs. Patch attached.
> >
> >Ta, I'll commit this along with the fbdev and nv stuff. Thanks for your
> >work - much appreciated.
>
> N/p. What are the changes in fbdev? Will it work now?
> I would like to test it because maybe it would work better than the
> current ati driver. :-)
The changes are mainly to the debrix core - the debrix module doesn't
build any libs anymore, only the one binary. Both fbdev and nv had deps
on variables inside Xorg (XAA/fbdevHW), so those needed to be folded
back into the main binary.
:) d
--
Daniel Stone <[email protected]>
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/20040628/a5b7833d/attach
ment.pgp
From loc at toya.net.pl Sun Jun 27 13:18:43 2004
From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Sun Jun 27 13:18:52 2004
Subject: [Xorg] debrix
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Sun, Jun 27, 2004 at 06:27:01PM +0200, Jakub Piotr C?apa wrote:
>>
>>You really should start using CVS. :D
>
> I had it all done at home, and tarballs uploaded (uploading 5MB sucks
> over a modem), so I scp'ed a diff, and imported to CVS from there (which
> was painful, because it came from X.Org, and had to be updated from
> XORG-RELEASE-1 and XDAMAGE-FIXES along the way, as well as some stuff
> from xserver).
>
> So, I had no CVS checkout. I swore I had one around somewhere, but no,
> couldn't find one. I'll grab it tonight.
Modem? I thought everybody living outside of Poland have a DSL these
days. :)
>>It was that simple! :D Of course the symbol problems disapear when i
>>don't try to use radeon directly. ;-)
>>Could we somehow ban this and print a BIG warning when sb. tries to load
>>sth strange as a display driver?
>
> I've been thinking about it, yes.
Cool. :) Same problem with 'fb' (it can be mistaken for fbdev).
>>Problems:
>>1. gnome-terminal draws all text in the upper left-hand corner of the
>> screen (xterm works fine). There are also some minor glitches in
>> xfwm4 window decorations. xfdesktop4 doesn't draw the background.
>> Maybe the reason is that all programs are built with X.org libs, not
>> xlibs from fdo.
>
> Interesting - maybe conflicting Xrender versions. Does rebuilding help?
> Sorry to be a pain in the butt ...
You are a pain? I thought I am the one who is. :D
I'll setup a chroot and build/run it there.
>>2. The server fails to restore the text mode (i get a blank screen
>> instead).
>
> Weird. That shouldn't happen - works for me on a Radeon 9000.
Radeon 9200. We can try to debug it later when I get a clear build.
>>>>3. autotoolization of debrix-driver-dummy has not been finished and
>>>> some includes lack proper dirs. Patch attached.
>>>
>>>Ta, I'll commit this along with the fbdev and nv stuff. Thanks for your
>>>work - much appreciated.
>>
>>N/p. What are the changes in fbdev? Will it work now?
>>I would like to test it because maybe it would work better than the
>>current ati driver. :-)
>
> The changes are mainly to the debrix core - the debrix module doesn't
> build any libs anymore, only the one binary. Both fbdev and nv had deps
> on variables inside Xorg (XAA/fbdevHW), so those needed to be folded
> back into the main binary.
Yup. That's what I have been thinking of. :) I managed to figure out
that building of fbdevhw is currently turned off.
Btw. My last e-mail ought to go to the list (and the previous one as
well). Are you sure Reply-to should be considered harmful? :D
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Sun Jun 27 13:23:36 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 27 13:23:41 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 27, 2004 at 10:18:43PM +0200, Jakub Piotr C??apa wrote:
> Daniel Stone wrote:
> > On Sun, Jun 27, 2004 at 06:27:01PM +0200, Jakub Piotr C?apa wrote:
> >>You really should start using CVS. :D
> >
> > I had it all done at home, and tarballs uploaded (uploading 5MB sucks
> > over a modem), so I scp'ed a diff, and imported to CVS from there (which
> > was painful, because it came from X.Org, and had to be updated from
> > XORG-RELEASE-1 and XDAMAGE-FIXES along the way, as well as some stuff
> > from xserver).
> >
> > So, I had no CVS checkout. I swore I had one around somewhere, but no,
> > couldn't find one. I'll grab it tonight.
>
> Modem? I thought everybody living outside of Poland have a DSL these
> days. :)
I live 3.8km from the exchange as the crow flies - more by the route the
wires actually take - and my street isn't cabled, because the cables are
all underground, and so there's really no reason to expend so much money
to connect 11 houses, when most of them probably don't want cable
anyway.
Trust me, I'd have broadband if I could. But this is Australia. :)
> >>It was that simple! :D Of course the symbol problems disapear when i
> >>don't try to use radeon directly. ;-)
> >>Could we somehow ban this and print a BIG warning when sb. tries to load
> >>sth strange as a display driver?
> >
> > I've been thinking about it, yes.
>
> Cool. :) Same problem with 'fb' (it can be mistaken for fbdev).
Thanks for the catch. Maybe it's worth renaming r128/atimisc/radeon to
ati-r128/ati-atimisc/ati-radeon or such, and then symlinking the old
names for compatibility?
> >>Problems:
> >>1. gnome-terminal draws all text in the upper left-hand corner of the
> >> screen (xterm works fine). There are also some minor glitches in
> >> xfwm4 window decorations. xfdesktop4 doesn't draw the background.
> >> Maybe the reason is that all programs are built with X.org libs, not
> >> xlibs from fdo.
> >
> > Interesting - maybe conflicting Xrender versions. Does rebuilding help?
> > Sorry to be a pain in the butt ...
>
> You are a pain? I thought I am the one who is. :D
> I'll setup a chroot and build/run it there.
Awesome, thanks a lot.
> >>2. The server fails to restore the text mode (i get a blank screen
> >> instead).
> >
> > Weird. That shouldn't happen - works for me on a Radeon 9000.
>
> Radeon 9200. We can try to debug it later when I get a clear build.
OK.
> > The changes are mainly to the debrix core - the debrix module doesn't
> > build any libs anymore, only the one binary. Both fbdev and nv had deps
> > on variables inside Xorg (XAA/fbdevHW), so those needed to be folded
> > back into the main binary.
>
> Yup. That's what I have been thinking of. :) I managed to figure out
> that building of fbdevhw is currently turned off.
It's not turned off, it's just currently built as a module
(libfbdevhw.la: lib_LTLIBRARIES = libfbdevhw.la, vs noinst_LIBRARIES =
libfbdevhw.a, and linked into the final binary).
> Btw. My last e-mail ought to go to the list (and the previous one as
> well). Are you sure Reply-to should be considered harmful? :D
Pretty sure, yep. I use group reply by default.
:) d
--
Daniel Stone <[email protected]>
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/20040628/f3adc3ba/attach
ment.pgp
From loc at toya.net.pl Sun Jun 27 13:35:06 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Sun Jun 27 13:35:10 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Sun, Jun 27, 2004 at 10:18:43PM +0200, Jakub Piotr C??apa wrote:
>
>>Daniel Stone wrote:
>>
>>>On Sun, Jun 27, 2004 at 06:27:01PM +0200, Jakub Piotr C?apa wrote:
>>>
>>>>You really should start using CVS. :D
>>>
>>>I had it all done at home, and tarballs uploaded (uploading 5MB sucks
>>>over a modem), so I scp'ed a diff, and imported to CVS from there (which
>>>was painful, because it came from X.Org, and had to be updated from
>>>XORG-RELEASE-1 and XDAMAGE-FIXES along the way, as well as some stuff
>>>from xserver).
>>>
>>>So, I had no CVS checkout. I swore I had one around somewhere, but no,
>>>couldn't find one. I'll grab it tonight.
>>
>>Modem? I thought everybody living outside of Poland have a DSL these
>>days. :)
>
> I live 3.8km from the exchange as the crow flies - more by the route the
> wires actually take - and my street isn't cabled, because the cables are
> all underground, and so there's really no reason to expend so much money
> to connect 11 houses, when most of them probably don't want cable
> anyway.
>
> Trust me, I'd have broadband if I could. But this is Australia. :)
I trust you. :D
>>>>It was that simple! :D Of course the symbol problems disapear when i
>>>>don't try to use radeon directly. ;-)
>>>>Could we somehow ban this and print a BIG warning when sb. tries to load
>>>>sth strange as a display driver?
>>>
>>>I've been thinking about it, yes.
>>
>>Cool. :) Same problem with 'fb' (it can be mistaken for fbdev).
>
> Thanks for the catch. Maybe it's worth renaming r128/atimisc/radeon to
> ati-r128/ati-atimisc/ati-radeon or such, and then symlinking the old
> names for compatibility?
Maybe. Tha main problem is Xorg binary loading sth as a driver without
complaining about it not being a driver. :D It should be checked somehow
IMHO. A list of display drivers + compatibile hardware (better - PCI
ids) would also be cool. (or is it actually done in -configure? tt also
failed for me)
>>>>Problems:
>>>>1. gnome-terminal draws all text in the upper left-hand corner of the
>>>> screen (xterm works fine). There are also some minor glitches in
>>>> xfwm4 window decorations. xfdesktop4 doesn't draw the background.
>>>> Maybe the reason is that all programs are built with X.org libs, not
>>>> xlibs from fdo.
>>>
>>>Interesting - maybe conflicting Xrender versions. Does rebuilding help?
>>>Sorry to be a pain in the butt ...
>>
>>You are a pain? I thought I am the one who is. :D
>>I'll setup a chroot and build/run it there.
>
> Awesome, thanks a lot.
It's me who is thanking a lot. :D
>>>The changes are mainly to the debrix core - the debrix module doesn't
>>>build any libs anymore, only the one binary. Both fbdev and nv had deps
>>>on variables inside Xorg (XAA/fbdevHW), so those needed to be folded
>>>back into the main binary.
>>
>>Yup. That's what I have been thinking of. :) I managed to figure out
>>that building of fbdevhw is currently turned off.
>
> It's not turned off, it's just currently built as a module
> (libfbdevhw.la: lib_LTLIBRARIES = libfbdevhw.la, vs noinst_LIBRARIES =
> libfbdevhw.a, and linked into the final binary).
Don't understand the difference (yet) but AFAIR fbdev is complaining
about missing fbdevhw.
>>Btw. My last e-mail ought to go to the list (and the previous one as
>>well). Are you sure Reply-to should be considered harmful? :D
>
> Pretty sure, yep. I use group reply by default.
So I have to change the way I'm used to use my e-mail program. (groups
I'm most active on set the Reply-To header) :D
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Sun Jun 27 13:41:01 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 27 13:41:03 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Sun, Jun 27, 2004 at 10:35:06PM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >On Sun, Jun 27, 2004 at 10:18:43PM +0200, Jakub Piotr C??apa wrote:
> >>Cool. :) Same problem with 'fb' (it can be mistaken for fbdev).
> >
> >Thanks for the catch. Maybe it's worth renaming r128/atimisc/radeon to
> >ati-r128/ati-atimisc/ati-radeon or such, and then symlinking the old
> >names for compatibility?
>
> Maybe. Tha main problem is Xorg binary loading sth as a driver without
> complaining about it not being a driver. :D It should be checked somehow
> IMHO. A list of display drivers + compatibile hardware (better - PCI
> ids) would also be cool. (or is it actually done in -configure? tt also
> failed for me)
Hm, interesting. I suppose we could error out if there's no relevant
DriverRec in the module we explicitly requested. I think
radeon/r128/whatever have an output DriverRec, tho.
That list would be really, really long, BTW. And I don't think there's
any standard interface to get all the PCI IDs.
> >It's not turned off, it's just currently built as a module
> >(libfbdevhw.la: lib_LTLIBRARIES = libfbdevhw.la, vs noinst_LIBRARIES =
> > libfbdevhw.a, and linked into the final binary).
>
> Don't understand the difference (yet) but AFAIR fbdev is complaining
> about missing fbdevhw.
Right. What happens is that you can't have module A depending on a
*variable* in module B, only a function. So if module A needs a variable
from module B, that just won't work - it has to be hidden behind a
function. In this case, fbdev/nv need variables from fbdevhw and xaa, so
fbdevhw and xaa can't be built as modules - they need to be built in to
the binary.
That's the executive summary.
> >>Btw. My last e-mail ought to go to the list (and the previous one as
> >>well). Are you sure Reply-to should be considered harmful? :D
> >
> >Pretty sure, yep. I use group reply by default.
>
> So I have to change the way I'm used to use my e-mail program. (groups
> I'm most active on set the Reply-To header) :D
Ah, sorry. That was the way fd.o was set up, and the way I'm used to - I
don't really want to change it, personally. ;)
Cheers!
-d
--
Daniel Stone <[email protected]>
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/20040628/d660f3bb/attach
ment.pgp
From loc at toya.net.pl Sun Jun 27 18:41:45 2004
From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Sun Jun 27 18:41:53 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Sun, Jun 27, 2004 at 10:35:06PM +0200, Jakub Piotr C?apa wrote:
>
>>Daniel Stone wrote:
>>
>>>On Sun, Jun 27, 2004 at 10:18:43PM +0200, Jakub Piotr C??apa wrote:
>>>
>>>>Cool. :) Same problem with 'fb' (it can be mistaken for fbdev).
>>>
>>>Thanks for the catch. Maybe it's worth renaming r128/atimisc/radeon to
>>>ati-r128/ati-atimisc/ati-radeon or such, and then symlinking the old
>>>names for compatibility?
>>
>>Maybe. Tha main problem is Xorg binary loading sth as a driver without
>>complaining about it not being a driver. :D It should be checked somehow
>>IMHO. A list of display drivers + compatibile hardware (better - PCI
>>ids) would also be cool. (or is it actually done in -configure? tt also
>>failed for me)
>
> Hm, interesting. I suppose we could error out if there's no relevant
> DriverRec in the module we explicitly requested. I think
> radeon/r128/whatever have an output DriverRec, tho.
IMHO we need something to distinguish module types. But don't ask me
what it should be... ;-) I'm not on this level of debrix hacking. :D
> That list would be really, really long, BTW. And I don't think there's
> any standard interface to get all the PCI IDs.
My /etc/pci.ids is only 256K and it contains lots more than graphic
cards (+ the names would not have to be duplicated and driver names are
shorter ;). Maybe it wouldn't be as long as you think?
>>>It's not turned off, it's just currently built as a module
>>>(libfbdevhw.la: lib_LTLIBRARIES = libfbdevhw.la, vs noinst_LIBRARIES =
>>>libfbdevhw.a, and linked into the final binary).
>>
>>Don't understand the difference (yet) but AFAIR fbdev is complaining
>>about missing fbdevhw.
>
> Right. What happens is that you can't have module A depending on a
> *variable* in module B, only a function. So if module A needs a variable
> from module B, that just won't work - it has to be hidden behind a
> function. In this case, fbdev/nv need variables from fbdevhw and xaa, so
> fbdevhw and xaa can't be built as modules - they need to be built in to
> the binary.
>
> That's the executive summary.
Now I understand. What you have broken is modules like pcidata ;-)
#v+
(EE) Failed to load module "pcidata" (module does not exist, 0)
Fatal server error:
Unable to load required base modules, Exiting...
#v-
Make them modules again or stop forcing to load them.
>>>>Btw. My last e-mail ought to go to the list (and the previous one as
>>>>well). Are you sure Reply-to should be considered harmful? :D
>>>
>>>Pretty sure, yep. I use group reply by default.
>>
>>So I have to change the way I'm used to use my e-mail program. (groups
>>I'm most active on set the Reply-To header) :D
>
> Ah, sorry. That was the way fd.o was set up, and the way I'm used to - I
> don't really want to change it, personally. ;)
Not a big deal, really. :D
While building in a clear enviroment I've catched some other problems
(patch is available [1]) (ordered as fixes appear in the diff)
1. compalloc.c - probably you forgot to commit it (it was commited into
xserver by mistake, then reverted); fixes building with
--enable-composite (haven't tried running because of the lack of
modules ;)
2. #include <X11/DECkeysym.h> - seems redundand to me and we don't have
this in debrix anywhere (it is in the Xorg tree - should be
imported?)
3. hw/xorg/include/X11/extensions/*.h header file weren't installed
4. same as 2
5. we have X11/Xdmcp.h and pkgconfig --cflags xdcmp returns
/usr/X11R6/include, not /usr/X11R6/include/X11
Hope that helps.
[1]http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-many_fixes.patch?rev=1
.2
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Sun Jun 27 18:56:57 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Sun Jun 27 18:56:59 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 03:41:45AM +0200, Jakub Piotr C??apa wrote:
> Daniel Stone wrote:
> >On Sun, Jun 27, 2004 at 10:35:06PM +0200, Jakub Piotr C?apa wrote:
> >>Maybe. Tha main problem is Xorg binary loading sth as a driver without
> >>complaining about it not being a driver. :D It should be checked somehow
> >>IMHO. A list of display drivers + compatibile hardware (better - PCI
> >>ids) would also be cool. (or is it actually done in -configure? tt also
> >>failed for me)
> >
> >Hm, interesting. I suppose we could error out if there's no relevant
> >DriverRec in the module we explicitly requested. I think
> >radeon/r128/whatever have an output DriverRec, tho.
>
> IMHO we need something to distinguish module types. But don't ask me
> what it should be... ;-) I'm not on this level of debrix hacking. :D
I'll put it on the TODO.
> >That list would be really, really long, BTW. And I don't think there's
> >any standard interface to get all the PCI IDs.
>
> My /etc/pci.ids is only 256K and it contains lots more than graphic
> cards (+ the names would not have to be duplicated and driver names are
> shorter ;). Maybe it wouldn't be as long as you think?
Hm.
> >>Don't understand the difference (yet) but AFAIR fbdev is complaining
> >>about missing fbdevhw.
> >
> >Right. What happens is that you can't have module A depending on a
> >*variable* in module B, only a function. So if module A needs a variable
> >from module B, that just won't work - it has to be hidden behind a
> >function. In this case, fbdev/nv need variables from fbdevhw and xaa, so
> >fbdevhw and xaa can't be built as modules - they need to be built in to
> >the binary.
> >
> >That's the executive summary.
>
> Now I understand. What you have broken is modules like pcidata ;-)
> #v+
> (EE) Failed to load module "pcidata" (module does not exist, 0)
>
> Fatal server error:
> Unable to load required base modules, Exiting...
> #v-
> Make them modules again or stop forcing to load them.
Ugh, that was a mistake. I need to fix the loader. But not now.
> >>So I have to change the way I'm used to use my e-mail program. (groups
> >>I'm most active on set the Reply-To header) :D
> >
> >Ah, sorry. That was the way fd.o was set up, and the way I'm used to - I
> >don't really want to change it, personally. ;)
>
> Not a big deal, really. :D
>
> While building in a clear enviroment I've catched some other problems
> (patch is available [1]) (ordered as fixes appear in the diff)
>
> 1. compalloc.c - probably you forgot to commit it (it was commited into
> xserver by mistake, then reverted); fixes building with
> --enable-composite (haven't tried running because of the lack of
> modules ;)
--enable-composite is really broken; waiting for a code drop from
anholt, who has it working.
> 2. #include <X11/DECkeysym.h> - seems redundand to me and we don't have
> this in debrix anywhere (it is in the Xorg tree - should be
> imported?)
I've already committed removing this, but thanks.
> 3. hw/xorg/include/X11/extensions/*.h header file weren't installed
Ah, fixed - ta.
> 5. we have X11/Xdmcp.h and pkgconfig --cflags xdcmp returns
> /usr/X11R6/include, not /usr/X11R6/include/X11
I've already committed this one, too.
Thanks a lot!
:) d
--
Daniel Stone <[email protected]>
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/20040628/f3b21793/attach
ment-0001.pgp
From elylevy-xserver at cs.huji.ac.il Mon Jun 28 01:09:53 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Mon Jun 28 01:09:58 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
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
3)I think there is some functionality missing like accelated moving
or tapping.
4)allowing more than one core device (mouse/keyboard) to be independed
from each other, It doesn't make much sense when using on one display
but if you want for example one keyboard per display for 2 people
working..
5)Personaly I think that xinput should handle keyboard as well,
(the basic hardware level not the xkb one), I don't know if it's related
to xinput but probebly some changes in they keysym handling might be
nice.
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Fri, 25 Jun 2004, [UTF-8] Kristian H?gsberg wrote:
> [ Joe, I'm cc'ing the list, I assume you meant to send to the list too ]
>
> Joe Krahn wrote:
> > Kristian H?gsberg wrote:
> > ...
> >
> >> One thing I'ld like to discuss is where to add the add and remove
> >> device interface -- I dont think XFree86-Misc is the right place. My
> >> first approach to this was that the new functionality should be an
> >> Xorg private interface, but I'm thinking that maybe it would be better
> >> if it was a standardized extension to XInput. In that case, is the
> >> proposed interface too Xorg specific?
> >
> >
> > OK... the big problem is a total lack of XINPUT design docs. (Or at
> > least that's how XFree86 was designed. I hope X.org is more interested
> > in fixing this.)
>
> Are you talking about the protocol design or the server internal
> (implementation) design? Or both?
>
From loc at toya.net.pl Mon Jun 28 04:06:42 2004
From: loc at toya.net.pl (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Mon Jun 28 04:06:51 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 03:41:45AM +0200, Jakub Piotr C??apa wrote:
>
>>While building in a clear enviroment I've catched some other problems
>>(patch is available [1]) (ordered as fixes appear in the diff)
Forgot about one - in
debrix/hw/xorg/os-support/shared/drm/kernel/drm.h there is an #include
of kernel config file. I'm pretty sure we should avoid this (and simply
removing this include semms to work... PLD has a patch for Xorg
monolitic tree that does no more than this and everything works fine).
More info (and why I had to remove this) here:
http://cvs.pld-linux.org/cgi-bin/cvsweb/linux-libc-headers/FAQ?rev=1.3
>>3. hw/xorg/include/X11/extensions/*.h header file weren't installed
>
> Ah, fixed - ta.
Are you sure? Now they go into /usr/include and something (AFAIR
debrix-driver-ati) expects them in /usr/include/X11/extensions. I would
suggest ext_HEADERS.
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Mon Jun 28 04:11:28 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 04:11:31 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 01:06:42PM +0200, Jakub Piotr C??apa wrote:
> Daniel Stone wrote:
> >On Mon, Jun 28, 2004 at 03:41:45AM +0200, Jakub Piotr C??apa wrote:
> >
> >>While building in a clear enviroment I've catched some other problems
> >>(patch is available [1]) (ordered as fixes appear in the diff)
>
> Forgot about one - in
> debrix/hw/xorg/os-support/shared/drm/kernel/drm.h there is an #include
> of kernel config file. I'm pretty sure we should avoid this (and simply
> removing this include semms to work... PLD has a patch for Xorg
> monolitic tree that does no more than this and everything works fine).
>
> More info (and why I had to remove this) here:
> http://cvs.pld-linux.org/cgi-bin/cvsweb/linux-libc-headers/FAQ?rev=1.3
Oops, did miss that one - thanks. I think the DRM bit is actually
intended to be built in-kernel: IIRC it's the kernel side of things,
designed to be built as a kernel module, so I'm going to leave that as I
don't know for sure either way.
> >>3. hw/xorg/include/X11/extensions/*.h header file weren't installed
> >
> >Ah, fixed - ta.
>
> Are you sure? Now they go into /usr/include and something (AFAIR
> debrix-driver-ati) expects them in /usr/include/X11/extensions. I would
> suggest ext_HEADERS.
Yep, I suck.
:) d
--
Daniel Stone <[email protected]>
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/20040628/5e957ea0/attach
ment.pgp
From michel at daenzer.net Mon Jun 28 04:23:09 2004
From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=)
Date: Mon Jun 28 04:23:18 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
Message-ID: <1088421789.17763.26.camel@localhost>
On Mon, 2004-06-28 at 13:06 +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> > On Mon, Jun 28, 2004 at 03:41:45AM +0200, Jakub Piotr C??apa wrote:
> >
> >>While building in a clear enviroment I've catched some other problems
> >>(patch is available [1]) (ordered as fixes appear in the diff)
>
> Forgot about one - in
> debrix/hw/xorg/os-support/shared/drm/kernel/drm.h there is an #include
> of kernel config file. I'm pretty sure we should avoid this (and simply
> removing this include semms to work... PLD has a patch for Xorg
> monolitic tree that does no more than this and everything works fine).
If this header file is indeed needed in userspace, the correct solution
would be to wrap the kernel specific parts in
#ifdef __KERNEL__
...
#endif
Not that this tree should build the DRM kernel modules at all (if the
DRM code in the kernel is too old, get the current code from the DRI CVS
drm module), but it might help merges.
--
Earthling Michel D?nzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
From loc at toya.net.pl Mon Jun 28 04:54:02 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Mon Jun 28 04:54:10 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 01:06:42PM +0200, Jakub Piotr C??apa wrote:
>
>>Daniel Stone wrote:
>>
>>>On Mon, Jun 28, 2004 at 03:41:45AM +0200, Jakub Piotr C??apa wrote:
>>>
>>>>While building in a clear enviroment I've catched some other problems
>>>>(patch is available [1]) (ordered as fixes appear in the diff)
>>
>>Forgot about one - in
>>debrix/hw/xorg/os-support/shared/drm/kernel/drm.h there is an #include
>>of kernel config file. I'm pretty sure we should avoid this (and simply
>>removing this include semms to work... PLD has a patch for Xorg
>>monolitic tree that does no more than this and everything works fine).
>>
>>More info (and why I had to remove this) here:
>>http://cvs.pld-linux.org/cgi-bin/cvsweb/linux-libc-headers/FAQ?rev=1.3
>
> Oops, did miss that one - thanks. I think the DRM bit is actually
> intended to be built in-kernel: IIRC it's the kernel side of things,
> designed to be built as a kernel module, so I'm going to leave that as I
> don't know for sure either way.
As i said - it builds that way, without errors. The monolitic tree also
works fine without this include.
btw. It ought to read "I forgot about one..." couse I haven't mentioned
it in my post. :D
>> >>3. hw/xorg/include/X11/extensions/*.h header file weren't installed
>>
>>>Ah, fixed - ta.
>>
>>Are you sure? Now they go into /usr/include and something (AFAIR
>>debrix-driver-ati) expects them in /usr/include/X11/extensions. I would
>>suggest ext_HEADERS.
>
> Yep, I suck.
I would argue. :D
PS. You sleep? Or eat? Or do anything else time-consuming? Every time I
write an e-mail you answer in less than 10 minutes. :D How are you doing
this? I'm impressed. ;-)
--
Regards,
Jakub Piotr C?apa
From peter at cendio.se Mon Jun 28 05:59:39 2004
From: peter at cendio.se (Peter Astrand)
Date: Mon Jun 28 05:59:43 2004
Subject: [Xorg] Crosscompile for Solaris
Message-ID: <[email protected]>
I'm trying to crosscompile X.org: Running the GNU toolchain on Linux,
producing code for Solaris. This is what I've tried:
1. Checked out xorg code from CVS, tagged with XORG-6_7_0.
2. Put this in config/cf/host.def:
#define HasFontconfig NO
#define HasGcc3 YES
#define CrossCompiling YES
#include <cross.def>
3. Changed config/cf/cross.def to:
#undef i386Architecture
#define SparcArchitecture
#undef BootstrapCFlags
#define BootstrapCFlags -Dsun -Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__
#undef StandardDefines
#define StandardDefines -Dsun -Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__
#define LdCmd gcc -nostdlib
#define SharedLibraryLoadFlags -shared
#define XFree86ServerDefines -DGCCUSESGAS
#define StdIncDir /usr/local/cross-solaris/sysroot/usr/include
#define PostIncDir /usr/local/cross-solaris/lib/gcc/sparc-sun-solaris2.8/3.4.0/i
nclude
#undef LdPostLib
#define LdPostLib -L/usr/local/cross-solaris/lib/
#include <cross.rules>
The CFLAGS lines has been invented pretty much by trial-and-error.
4. Building with:
make World CROSSCOMPILEDIR=/usr/local/cross-solaris/sparc-sun-solaris2.8/bin
It doesn't work. I have several problems:
a) imake segfaults in get_sun_compiler_versions. I've fixed this by making
get_sun_compiler_versions a dummy no-op.
b) The compilation of some components fails, but the build process does
not stop. Is this normal? It makes it harder to track down errors.
c) I'm getting all kinds of errors. Here's one example, when compiling
xterm:
/usr/local/cross-solaris/sparc-sun-solaris2.8/bin/`echo gcc|sed "s%.*/%%"`
-O2 -I. -I../../exports/include -I../../exports/include
-I../../exports/include/freetype2 -I../../exports/include/freetype2/config
-I../../exports/include/X11 -I../.. -I../../exports/include -Dsun
-Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__ -DSCROLLBAR_RIGHT
-DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2
-DPROJECTROOT=/usr/X11R6 -DXVERSION='"4.3.99.3"' -DXVENDORNAME='"The
X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' -c -o resize.o resize.c
In file included from ./ptyx.h:77,
from ./xterm.h:237,
from resize.c:61:
../../exports/include/X11/Xft/Xft.h:43:35: fontconfig/fontconfig.h: No
such file or directory
In file included from ../../exports/include/X11/Xft/Xft.h:50,
from ./ptyx.h:77,
from ./xterm.h:237,
from resize.c:61:
../../exports/include/X11/Xft/XftCompat.h:33: error: parse error before
"XftChar8"
I'm only interested in building Xvfb, so it doesn't matter if programs
such as "xterm" fails to build, though.
What am I doing wrong here? Has anyone succeeded with crosscompiling
X.org/XF86 for Solaris? Any ideas?
--
Peter ?strand Chief Developer
Cendio www.thinlinc.com
Teknikringen 3 www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jun 28 06:17:58 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Jun 28 06:18:02 2004
Subject: [Xorg] Crosscompile for Solaris
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, 28 Jun 2004, Peter Astrand wrote:
>
> I'm trying to crosscompile X.org: Running the GNU toolchain on Linux,
> producing code for Solaris. This is what I've tried:
>
> 1. Checked out xorg code from CVS, tagged with XORG-6_7_0.
>
>
> 2. Put this in config/cf/host.def:
>
> #define HasFontconfig NO
> #define HasGcc3 YES
> #define CrossCompiling YES
> #include <cross.def>
The last two are not required (afaik). Setting CROSSCOMPILEDIR does include
cross.def and sets CrossCompiling too.
> 3. Changed config/cf/cross.def to:
>
> #undef i386Architecture
> #define SparcArchitecture
> #undef BootstrapCFlags
> #define BootstrapCFlags -Dsun -Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__
> #undef StandardDefines
> #define StandardDefines -Dsun -Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__
> #define LdCmd gcc -nostdlib
> #define SharedLibraryLoadFlags -shared
> #define XFree86ServerDefines -DGCCUSESGAS
> #define StdIncDir /usr/local/cross-solaris/sysroot/usr/include
> #define PostIncDir /usr/local/cross-solaris/lib/gcc/sparc-sun-solaris2.8/3.4.0
/include
> #undef LdPostLib
> #define LdPostLib -L/usr/local/cross-solaris/lib/
> #include <cross.rules>
>
> The CFLAGS lines has been invented pretty much by trial-and-error.
>
>
> 4. Building with:
>
> make World CROSSCOMPILEDIR=/usr/local/cross-solaris/sparc-sun-solaris2.8/bin
I'm doing crosscompile for cygwin on linux and I've no problems. But I've adjust
ed
some files in config/imake and config/makedepend to workaround some problems.
> It doesn't work. I have several problems:
>
> a) imake segfaults in get_sun_compiler_versions. I've fixed this by making
> get_sun_compiler_versions a dummy no-op.
>
> b) The compilation of some components fails, but the build process does
> not stop. Is this normal? It makes it harder to track down errors.
I've noticed this too. Just write all make output to a file and grep for "***"
make World CROSSCOMPILEDIR=... 2>&1 | tee makelog
and in another xterm I wathc the logfile and search for "***" (regex \*\*\*) and
try to fix the errors.
> c) I'm getting all kinds of errors. Here's one example, when compiling
> xterm:
>
> /usr/local/cross-solaris/sparc-sun-solaris2.8/bin/`echo gcc|sed "s%.*/%%"`
> -O2 -I. -I../../exports/include -I../../exports/include
> -I../../exports/include/freetype2 -I../../exports/include/freetype2/config
> -I../../exports/include/X11 -I../.. -I../../exports/include -Dsun
> -Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__ -DSCROLLBAR_RIGHT
> -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2
> -DPROJECTROOT=/usr/X11R6 -DXVERSION='"4.3.99.3"' -DXVENDORNAME='"The
> X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' -c -o resize.o resize.c
> In file included from ./ptyx.h:77,
> from ./xterm.h:237,
> from resize.c:61:
> ../../exports/include/X11/Xft/Xft.h:43:35: fontconfig/fontconfig.h: No
> such file or directory
You don't have fontconfig (cross version) installed. Add this to your host.def:
#define HasFontconfig NO
#define HasExpat NO
#define HasMotif NO
#define HasMotif2 NO
maybe there are some other libraries which are not present as crosscompile versi
ons
which have to be added to. make World will then compile a local fontconfig and e
xpat
library and discard everything that requires motif.
> I'm only interested in building Xvfb, so it doesn't matter if programs
> such as "xterm" fails to build, though.
You could add
#define BuildClients NO
#define BuildFonts NO
#define BuildDocs NO
#define BuildServers YES
to host.def
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From mariusd at pasco.co.za Mon Jun 28 06:33:07 2004
From: mariusd at pasco.co.za (marius du plessis)
Date: Mon Jun 28 06:33:12 2004
Subject: [Xorg] projector resolution issues...
Message-ID: <[email protected]>
Hi guys
We've run into a general problem in Fedora 2 when connecting an external
projector to our machines. The projector supports resolutions up to
1280 x 1024 (Vsync - 60Hz, Hsync 64Hz), but as soon as we connect it to
our machines it only displays at 640x480.
I've checked all the frequency compatibilities, as well as resolution
compatibilities and everything is in sync. Even went through xorg.conf,
and all the settings and recommendations found through googling is
already in by default.
By the way - the projector works fine in Windoze - on all of the
frequencies and resolutions....
If it is a known issue, or if a work - around exists, please let me know
as we do quite a lot of presentations and training....
thanx
--
________________________________________________________________________________
Regards,
Marius du Plessis
Pasco Risk Consultants (Pty) Ltd Pasco Risk Consultants (Pty) Ltd
32 Gazelle Close P.O.Box 789
Corporate Park South Douglasdale
Randjiesfontein 1683 2165
Direct Line: +27 (0)11 542 2911 Cell: +27(0)83 756 4521
Switchboard: +27 (0)11 542 2900 Fax: +27 (0)11 542 2916
http://www.pasco.co.za
________________________________________________________________________________
This e-mail is intended only for the confidential use of the intended
recipient. Review, dissemination, distribution or copying of this e-mail
is strictly prohibited if you are not the intended recipient. If you
have received it in error please notify us of the error immediately.
From daniel at freedesktop.org Mon Jun 28 06:48:38 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 06:48:43 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 01:54:02PM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >Yep, I suck.
>
> I would argue. :D
>
> PS. You sleep? Or eat? Or do anything else time-consuming? Every time I
> write an e-mail you answer in less than 10 minutes. :D How are you doing
> this? I'm impressed. ;-)
It's been a while since I slept, but I was just in the middle of making
these really nice sausage rolls. Real fat beefy sausages, gutted for the
meat, with basil and lots of other spices, and real cracked pepper, and
a bit of real beef stock. Unfortunately the filo pastry is crap, I
think. Maybe it'll work OK. We'll see.
I think it's been almost an hour since you posted. How's that? :)
:) d
--
Daniel Stone <[email protected]>
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/20040628/f7701b97/attach
ment-0001.pgp
From alan at lxorguk.ukuu.org.uk Mon Jun 28 05:46:23 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Mon Jun 28 06:49:25 2004
Subject: [Xorg] projector resolution issues...
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Llu, 2004-06-28 at 14:33, marius du plessis wrote:
> Hi guys
>
> We've run into a general problem in Fedora 2 when connecting an external
> projector to our machines. The projector supports resolutions up to
> 1280 x 1024 (Vsync - 60Hz, Hsync 64Hz), but as soon as we connect it to
> our machines it only displays at 640x480.
I would guess the projector doesn't report its properties with DDC. If
so you want to edit Xorg.conf and uncomment the frequency ranges. This
is probably an item for fedora-list as its not an Xorg bug but a Fedora
configuration policy discussion..
From peter at cendio.se Mon Jun 28 07:19:53 2004
From: peter at cendio.se (Peter Astrand)
Date: Mon Jun 28 07:19:59 2004
Subject: [Xorg] Crosscompile for Solaris
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On Mon, 28 Jun 2004, Alexander Gottwald wrote:
> > I'm trying to crosscompile X.org: Running the GNU toolchain on Linux,
> > producing code for Solaris. This is what I've tried:
> >
> > 1. Checked out xorg code from CVS, tagged with XORG-6_7_0.
> >
> >
> > 2. Put this in config/cf/host.def:
> >
> > #define HasFontconfig NO
> > #define HasGcc3 YES
> > #define CrossCompiling YES
> > #include <cross.def>
>
> The last two are not required (afaik). Setting CROSSCOMPILEDIR does include
> cross.def and sets CrossCompiling too.
It doesn't work for me without those. If I don't have those, cross.def is
not parsed at all (I've tested this by inserting a #error line).
> > /usr/local/cross-solaris/sparc-sun-solaris2.8/bin/`echo gcc|sed "s%.*/%%"`
> > -O2 -I. -I../../exports/include -I../../exports/include
> > -I../../exports/include/freetype2 -I../../exports/include/freetype2/config
> > -I../../exports/include/X11 -I../.. -I../../exports/include -Dsun
> > -Dsparc -DSVR4 -D__SVR4 -D__EXTENSIONS__ -DSCROLLBAR_RIGHT
> > -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2
> > -DPROJECTROOT=/usr/X11R6 -DXVERSION='"4.3.99.3"' -DXVENDORNAME='"The
> > X.Org Foundation"' -DXVENDORNAMESHORT='"X.Org"' -c -o resize.o resize.c
> > In file included from ./ptyx.h:77,
> > from ./xterm.h:237,
> > from resize.c:61:
> > ../../exports/include/X11/Xft/Xft.h:43:35: fontconfig/fontconfig.h: No
> > such file or directory
>
> You don't have fontconfig (cross version) installed. Add this to your host.def
:
>
> #define HasFontconfig NO
> #define HasExpat NO
> #define HasMotif NO
> #define HasMotif2 NO
Thanks.
> You could add
> #define BuildClients NO
> #define BuildFonts NO
> #define BuildDocs NO
> #define BuildServers YES
>
> to host.def
I have now been able to produce a Xvfb binary. Some additional problems:
1) The build of "Xsun" failed, with:
sunCfb.c:311:24: sys/cg2reg.h: No such file or directory
What's the easiest way of disabling the build of Xsun?
2) Xvfb wanted to link with "-lfreetype". This failed, because no
"libfreetype.so" existed in the exports/lib directory. This was solved by
a symlink:
ln -s libfreetype.so.9.0 libfreetype.so
3) I needed to manually make Xvfb link with "-lnsl -lsocket". I wonder why
the definition of ExtraLibraries from sun.cf was not used.
Now I just have to figure out how to link libfreetype statically...
--
Peter ?strand Chief Developer
Cendio www.thinlinc.com
Teknikringen 3 www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00
From alexander.gottwald at s1999.tu-chemnitz.de Mon Jun 28 08:07:48 2004
From: alexander.gottwald at s1999.tu-chemnitz.de (Alexander Gottwald)
Date: Mon Jun 28 08:07:52 2004
Subject: [Xorg] Crosscompile for Solaris
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, 28 Jun 2004, Peter Astrand wrote:
> On Mon, 28 Jun 2004, Alexander Gottwald wrote:
> > >
> > > 2. Put this in config/cf/host.def:
> > >
> > > #define HasFontconfig NO
> > > #define HasGcc3 YES
> > > #define CrossCompiling YES
> > > #include <cross.def>
> >
> > The last two are not required (afaik). Setting CROSSCOMPILEDIR does include
> > cross.def and sets CrossCompiling too.
>
> It doesn't work for me without those. If I don't have those, cross.def is
> not parsed at all (I've tested this by inserting a #error line).
hm yes. We have this in cgwin.cf
#if CrossCompiling
#include <cross.def>
#endif
> > You don't have fontconfig (cross version) installed. Add this to your host.d
ef:
> >
> > #define HasFontconfig NO
> > #define HasExpat NO
> > #define HasMotif NO
> > #define HasMotif2 NO
>
> Thanks.
>
> > You could add
> > #define BuildClients NO
> > #define BuildFonts NO
> > #define BuildDocs NO
> > #define BuildServers YES
> >
> > to host.def
>
> I have now been able to produce a Xvfb binary. Some additional problems:
>
> 1) The build of "Xsun" failed, with:
>
> sunCfb.c:311:24: sys/cg2reg.h: No such file or directory
>
> What's the easiest way of disabling the build of Xsun?
#define XsunServer NO
> 2) Xvfb wanted to link with "-lfreetype". This failed, because no
> "libfreetype.so" existed in the exports/lib directory. This was solved by
> a symlink:
>
> ln -s libfreetype.so.9.0 libfreetype.so
This is normally done by the SharedLibraryTarget rule. maybe is it not defined
properly
> 3) I needed to manually make Xvfb link with "-lnsl -lsocket". I wonder why
> the definition of ExtraLibraries from sun.cf was not used.
> Now I just have to figure out how to link libfreetype statically...
bye
ago
--
[email protected]
http://www.gotti.org ICQ: 126018723
From loc at toya.net.pl Mon Jun 28 08:09:30 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Mon Jun 28 08:09:45 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 01:54:02PM +0200, Jakub Piotr C?apa wrote:
>
>>Daniel Stone wrote:
>>
>>>Yep, I suck.
>>
>>PS. You sleep? Or eat? Or do anything else time-consuming? Every time I
>>write an e-mail you answer in less than 10 minutes. :D How are you doing
>>this? I'm impressed. ;-)
>
> It's been a while since I slept, but I was just in the middle of making
> these really nice sausage rolls. Real fat beefy sausages, gutted for the
> meat, with basil and lots of other spices, and real cracked pepper, and
> a bit of real beef stock. Unfortunately the filo pastry is crap, I
> think. Maybe it'll work OK. We'll see.
I hope it worked. If not you will be in bad mood. :D
> I think it's been almost an hour since you posted. How's that? :)
I don't recall saying I'm unhappy with you reply time. :D
I was playing a bit more with the source and found out:
- ati tries to load fbdevhw and fails. when i comment out
radeon_driver.c:3991 it complains about missing vgaHWGetHWRec.
'nm Xorg | grep vga' displays nothing.
I don't really understand why symbols from scanpci are exported and
those from vgahw aren't... They look identical to me (If they were we
could just remove the line 3991 from radeon_driver or change
xf86LoadSubModule so it would return TRUE for builtin modules)
- when I remove the pcidata from the baseModules list
(hw/xorg/common/xf86Init.c:120) it catches SIGSEGV in
x86pciBus.c:1732 - xf86SetupPciIds == NULL.
It seems to work when we remove the conditional build (that is:
sed -ie '1712,1723d;1730d;' x86pciBus.c)
Is there any use in me playing with this apart from learning (that's me)
and loosing time (that's you)? :) I would love to help and learn
something new (I've only played with simpler C programs before) but
maybe it is not the right moment for this?
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Mon Jun 28 08:13:10 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 08:13:12 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 05:09:30PM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >On Mon, Jun 28, 2004 at 01:54:02PM +0200, Jakub Piotr C?apa wrote:
> >
> >>Daniel Stone wrote:
> >>
> >>>Yep, I suck.
> >>
> >>PS. You sleep? Or eat? Or do anything else time-consuming? Every time I
> >>write an e-mail you answer in less than 10 minutes. :D How are you doing
> >>this? I'm impressed. ;-)
> >
> >It's been a while since I slept, but I was just in the middle of making
> >these really nice sausage rolls. Real fat beefy sausages, gutted for the
> >meat, with basil and lots of other spices, and real cracked pepper, and
> >a bit of real beef stock. Unfortunately the filo pastry is crap, I
> >think. Maybe it'll work OK. We'll see.
>
> I hope it worked. If not you will be in bad mood. :D
Yeah, the filo was stuffed, and I have to start again.
> >I think it's been almost an hour since you posted. How's that? :)
>
> I don't recall saying I'm unhappy with you reply time. :D
I was just pointing out that it's not quite ten minutes. Sometimes I do
other things!
> I was playing a bit more with the source and found out:
>
> - ati tries to load fbdevhw and fails. when i comment out
> radeon_driver.c:3991 it complains about missing vgaHWGetHWRec.
> 'nm Xorg | grep vga' displays nothing.
> I don't really understand why symbols from scanpci are exported and
> those from vgahw aren't... They look identical to me (If they were we
> could just remove the line 3991 from radeon_driver or change
> xf86LoadSubModule so it would return TRUE for builtin modules)
It's because unused symbols are garbage-collected; to prevent this
happening, put SYMFUNC(foo), or SYMVAR(foo) in loader/xf86sym.c,
depending on whether it's a function or variable.
> - when I remove the pcidata from the baseModules list
> (hw/xorg/common/xf86Init.c:120) it catches SIGSEGV in
> x86pciBus.c:1732 - xf86SetupPciIds == NULL.
> It seems to work when we remove the conditional build (that is:
> sed -ie '1712,1723d;1730d;' x86pciBus.c)
pcidata needs to be a module, probably. Or retain all of its symbols.
> Is there any use in me playing with this apart from learning (that's me)
> and loosing time (that's you)? :) I would love to help and learn
> something new (I've only played with simpler C programs before) but
> maybe it is not the right moment for this?
Sure - hopefully it'll be *the* new X server. Doesn't seem like the
worst way to get into X development, either. :)
--
Daniel Stone <[email protected]>
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/20040629/998ecee1/attach
ment.pgp
From eich at pdx.freedesktop.org Mon Jun 28 08:17:28 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Jun 28 08:18:19 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: [email protected] wrote on Wednesday,
23 June 2004 at 19:36:46 +0200
References: <[email protected]>
Message-ID: <[email protected]>
Kristian H=F8gsberg writes:
> Hi all,
> =
> I've been working on making the X.org server hotplug aware with respec=
t
> to input devices. The current situation is that all devices must be =
> setup in the config file and adding new devices requires config file =
> editing and server restart. What I've been trying to implement is tha=
t =
> you can plug in an input device while the X server is running and it =
> will show up as a new XInput device.
> =
> The overall design I'm thinking of is to keep the device discovery =
> mechanism out of the X server. By adding requests to add and remove
> devices a client program can monitor hotplug events and tell the serve=
r =
> to add or remove devices accordingly.
Having the discover mechanism live outside of the X server is only useful=
if
it is generic to the system and not specific to X. Any program interested=
in input devices should be able to take advantage of its services.
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. =
At the same time there may be valid reasons why multiple programs obtain
data from the same device. (The solution that comes to my mind is to
register MASTER and SLAVE applications and to make sure that only one =
MASTER app is allowed to open the device).
> =
> I have a prototype running were I've added AddInputDevice() and
> RemoveInputDevice() in the XFree86-Misc extension:
> =
> typedef struct {
> char* name;
> char* value;
> } XF86MiscDriverOption;
> =
> Status XF86MiscAddInputDevice(Display *dpy,
> const char *identifier,
> const char *driver,
> XF86MiscDriverOption *options,
> int option_count);
> =
> Status XF86MiscRemoveInputDevice(Display *dpy,
> const char *identifier);
> =
> i.e. the AddInputDevice arguments correspond to the InputDevice sectio=
n =
> of the config file. The implementation mimicks the server =
> initialization sequence; it loads the driver, builds an option list fr=
om =
> the given options, calls PreInit(), and adds the device.
> =
> In the prototype I'm using HAL (hal.freedesktop.org) on Linux to =
> enumerate and discover devices. Other systems could use other =
> mechanisms, but HAL is intended to be cross platform, and a FreeBSD po=
rt =
> is being discussed right now on the list.
> =
> One thing I'ld like to discuss is where to add the add and remove devi=
ce =
> interface -- I dont think XFree86-Misc is the right place. My first =
> approach to this was that the new functionality should be an Xorg =
> private interface, but I'm thinking that maybe it would be better if i=
t =
> was a standardized extension to XInput. In that case, is the proposed=
=
> interface too Xorg specific?
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 communica=
te
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.
The XInput extension may have to be extended to be able to send events
to notify clients about the new device. Also it may be useful to provide
more information about the device to the clients (for example some ID
or serial number) so the client is able to (re)identify devices.
> =
> Comments are welcome. I'm currently trying to get my prototype cleane=
d =
> up, and then I'll attach it to a bugzilla entry
> =
I hope my comments have been helpful. This is certainly an importand issu=
e
which should be discussed.
Egbert.
From eich at pdx.freedesktop.org Mon Jun 28 08:21:28 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Jun 28 08:22:14 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: [email protected] wrote on Thursday,
24 June 2004 at 21:30:52 -0400
References: <[email protected]> <[email protected]>
Message-ID: <[email protected]>
Keith Packard writes:
>
> Around 19 o'clock on Jun 23, =?ISO-8859-1?Q?Kristian_H=F8gsberg?= wrote:
>
> > 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.
>
> > One thing I'ld like to discuss is where to add the add and remove device
> > interface
>
> I'd like to think this belongs in the XInput extension. There are other
> changes which we can add to that extension at the same time and rev the
> protocol version. Coding up backward-compatibility stuff will also be
> necessary; take a look at how XFixes manages that (client sends its
> version number, X server ensures protocol is compatible with that version).
>
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.
Egbert.
From eich at pdx.freedesktop.org Mon Jun 28 08:22:02 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Jun 28 08:22:48 2004
Subject: [Xorg] Mozilla tinderbox and bonsai
In-Reply-To: [email protected] wrote on Sunday, 20 June 2004 at 03:01:20 -0700
References: <[email protected]>
<Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il>
<[email protected]>
<1087725680.1032.144.camel@leguin>
Message-ID: <[email protected]>
Eric Anholt writes:
>
> I couldn't think of anything before, but was reminded tonight on irc.
>
> cvsup!
>
This stuff should all be documented on the wiki. I've started sections
on cvs and cvsup and a few other things. You will find those when you
follow the link to the development pages from the entry page wiki.x.org.
I hope that some people join me in making this section really useful.
Egbert.
From keithp at keithp.com Mon Jun 28 08:30:13 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 28 08:30:32 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: Your message of "Mon, 28 Jun 2004 17:17:28 +0200."
<[email protected]>
Message-ID: <[email protected]>
Around 17 o'clock on Jun 28, Egbert Eich wrote:
> Having the discover mechanism live outside of the X server is only useful
> if it is generic to the system and not specific to X. Any program
> interested in input devices should be able to take advantage of its
> services.
The HAL mechanism should be able to manage the device discovery, and if
that device is using the standard Linux input drivers, it should be easy
to make the X server handle essentially any new device without new code.
The only X specific piece would be a connector that listened for HAL
messages and converted them to the appropriate X protocol.
The obvious alternative would be to embed that functionality into the X
server, but I can easily imagine wanting to control the policy and
management of those devices from user-mode, in which case we'd end up
adding lots of additional protocol or just do all of that in an X
application.
Let's try the external application first and see how it looks; we can
always change things before we standardize.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040628/4194dbe9/attach
ment.pgp
From loc at toya.net.pl Mon Jun 28 08:38:11 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Mon Jun 28 08:38:19 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 05:09:30PM +0200, Jakub Piotr C?apa wrote:
>
>>I was playing a bit more with the source and found out:
>>
>>- ati tries to load fbdevhw and fails. when i comment out
>> radeon_driver.c:3991 it complains about missing vgaHWGetHWRec.
>> 'nm Xorg | grep vga' displays nothing.
>> I don't really understand why symbols from scanpci are exported and
>> those from vgahw aren't... They look identical to me (If they were we
>> could just remove the line 3991 from radeon_driver or change
>> xf86LoadSubModule so it would return TRUE for builtin modules)
>
> It's because unused symbols are garbage-collected; to prevent this
> happening, put SYMFUNC(foo), or SYMVAR(foo) in loader/xf86sym.c,
> depending on whether it's a function or variable.
'cd debrix; grep -R ScanPciSetupPciIds *' doesn't show anything
connected with SYMFUNC :( I would have probably figured it out if it did.
Also grep -R SYMFUNC\|SYMVAR * doesn't show anything connected with
PciIds. Is there any other place it could get protected from garbage
collection?
>>- when I remove the pcidata from the baseModules list
>> (hw/xorg/common/xf86Init.c:120) it catches SIGSEGV in
>> x86pciBus.c:1732 - xf86SetupPciIds == NULL.
>> It seems to work when we remove the conditional build (that is:
>> sed -ie '1712,1723d;1730d;' x86pciBus.c)
>
> pcidata needs to be a module, probably. Or retain all of its symbols.
The problem is that it retains (maybe not all, but all that are used
before loading libradeon.so which fails for me). I can't figure out how
however.
#v+
bash-2.05b# nm ../BUILD/debrix/hw/xorg/Xorg |grep ScanPci
080ad280 T DoScanPci
080c25d0 T ScanPciClosePciIds
080c2930 T ScanPciDisplayPCICardInfo
080c28c0 T ScanPciFindPciClassByDevice
080c2850 T ScanPciFindPciClassBySubsys
080c25e0 T ScanPciFindPciNamesByDevice
080c27a0 T ScanPciFindPciNamesBySubsys
080c25c0 T ScanPciSetupPciIds
#v-
>>Is there any use in me playing with this apart from learning (that's me)
>>and loosing time (that's you)? :) I would love to help and learn
>>something new (I've only played with simpler C programs before) but
>>maybe it is not the right moment for this?
>
> Sure - hopefully it'll be *the* new X server. Doesn't seem like the
> worst way to get into X development, either. :)
Cool! So I will continue. Beware! :D
--
Regards,
Jakub Piotr C?apa
From daniel at freedesktop.org Mon Jun 28 08:54:17 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 08:54:19 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 05:42:15PM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >Nope. I guess the code has always just relied on it being a module. Try
> >removing the two scanpci libraries from the Xorg linking in
> >hw/xorg/Makefile.am, and changing hw/xorg/scanpci/Makefile.am:
> >noinst_LIBRARIES = libscanpci.a libpcidata.a
> >libscanpci_a_SOURCES = foo
> >libpcidata_a_SOURCES = bar
> >--
> >to:
> >lib_LTLIBRARIES = libscanpci.la libpcidata.la
> >libscanpci_la_SOURCES = foo
> >libpcidata_la_SOURCES = bar
>
> Tried. Works either way. When compiled in I just disable the probing
> stuff from xf86pciBus.c lines 1712-1730 + remove it from the baseModules
> and it works.
Hm, cool.
> >Hrm. I have on idea without an extended look, and I have to start this
> >stupid pastry again.
>
> It would help if I knew how to get vgahw symbols exported. (and why
> these are).
If function foosym needs to be exported, you need to add:
SYMFUNC(foosym);
to hw/xorg/loader/xf86sym.c; if it's a variable:
SYMVAR(foosym);
> I'm leaving now and be back in several hours so no need to hurry. :)
I'm going to try the filo pastry. Again.
:) d
--
Daniel Stone <[email protected]>
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/20040629/04630022/attach
ment.pgp
From eich at pdx.freedesktop.org Mon Jun 28 08:48:29 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Jun 28 08:55:35 2004
Subject: [Xorg] VSW4 test suite
Message-ID: <[email protected]>
I don't see any pointer on the X.Org web site nor on the wiki
to the VSW4 test suite (the last version that is entirely freely
usable). It would help a lot if this suite was available on
CVS and if there was documentation someplace on how to build and
run it.
I'd even like suggest to make a run part of our tinderbox test
suite. It is obvious that it will not catch every error that
may occur but it will test the functionality of the core protocol
(including some extensions I believe) and some problems may be
detected early.
If someone could give me a pointer to the (original) sources I
would take care of adding it to CVS and put up some documentation.
Egbert.
From dustymugs at skewedperception.com Mon Jun 28 09:41:36 2004
From: dustymugs at skewedperception.com (DustyMugs)
Date: Mon Jun 28 09:39:35 2004
Subject: [Xorg] Compiling from tarballs
Message-ID: <[email protected]>
Hi,
I couldn't find a more appropriate mailing list to ask this question,
but hopefully this place will do.
I got all 7 tarballs from x.org of the latest release and following the
instructions for building it. But the build fails with ft2build.h file
or directory not found error. So, i tried to fix it by installing a
build of freetype2. Now, the error isn't ft2build.h but rather
ftheader.h is unable to be found.
Following the directions didn't help me. Any help would be great. I'm
currently running 2.4.26 with gcc 3.3.4.
Thanks,
Bborie Park
From eich at pdx.freedesktop.org Mon Jun 28 10:27:49 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Mon Jun 28 10:29:24 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: [email protected] wrote on Monday, 28 June 2004 at 08:30:13 -0700
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Keith Packard writes:
>
> Around 17 o'clock on Jun 28, Egbert Eich wrote:
>
> > Having the discover mechanism live outside of the X server is only useful
> > if it is generic to the system and not specific to X. Any program
> > interested in input devices should be able to take advantage of its
> > services.
>
> The HAL mechanism should be able to manage the device discovery, and if
> that device is using the standard Linux input drivers, it should be easy
> to make the X server handle essentially any new device without new code.
>
> The only X specific piece would be a connector that listened for HAL
> messages and converted them to the appropriate X protocol.
>
> The obvious alternative would be to embed that functionality into the X
> server, but I can easily imagine wanting to control the policy and
> management of those devices from user-mode, in which case we'd end up
> adding lots of additional protocol or just do all of that in an X
> application.
We definitely need some agent that dispatches the input devices among
different user mode programs. Making this sit inside the Xserver would
bind it to a single X server which would make moving towards multi seat
capabilities even more difficult.
I only would like to see this agent to be indepent of X. Also this begs
the question why this functionality could not be implemented directly into
HAL.
Egbert.
From mfrey at pepper.com Mon Jun 28 11:06:50 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 11:06:57 2004
Subject: [Xorg] Error building X11
Message-ID: <[email protected]>
I am trying to build the latest and I get the following build error
when building X11.
xscale_le-gcc -DHAVE_CONFIG_H -I. -I. -I. -include config.h
-I../include -I../include/X11 -Wall -Wpointer-arith -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations -Wnested-externs
-fno-strict-aliasing -D_BSD_SOURCE -I/opt/fdo/include
-I/opt/fdo/include/X11/Xtrans -D_XOPEN_SOURCE -I/opt/fdo/include
-DXTHREADS -DXUSE_MTSAFE_API -DX11_DATADIR=\"/opt/fdo/share/X11\" -g
-O2 -MT GetDflt.lo -MD -MP -MF .deps/GetDflt.Tpo -c GetDflt.c -fPIC
-DPIC -o .libs/GetDflt.o
GetDflt.c: In function `XGetDefault':
GetDflt.c:240: error: `XlibDispayDfltRMDB' undeclared (first use in
this function)
GetDflt.c:240: error: (Each undeclared identifier is reported only once
GetDflt.c:240: error: for each function it appears in.)
make[3]: *** [GetDflt.lo] Error 1
Any ideas?
Thanks,
Michael
From daniel at freedesktop.org Mon Jun 28 11:16:25 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 11:16:27 2004
Subject: [Xorg] Error building X11
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 02:06:50PM -0400, Michael Frey wrote:
> I am trying to build the latest and I get the following build error
> when building X11.
>
> xscale_le-gcc -DHAVE_CONFIG_H -I. -I. -I. -include config.h
> -I../include -I../include/X11 -Wall -Wpointer-arith -Wstrict-prototypes
> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs
> -fno-strict-aliasing -D_BSD_SOURCE -I/opt/fdo/include
> -I/opt/fdo/include/X11/Xtrans -D_XOPEN_SOURCE -I/opt/fdo/include
> -DXTHREADS -DXUSE_MTSAFE_API -DX11_DATADIR=\"/opt/fdo/share/X11\" -g
> -O2 -MT GetDflt.lo -MD -MP -MF .deps/GetDflt.Tpo -c GetDflt.c -fPIC
> -DPIC -o .libs/GetDflt.o
> GetDflt.c: In function `XGetDefault':
> GetDflt.c:240: error: `XlibDispayDfltRMDB' undeclared (first use in
> this function)
> GetDflt.c:240: error: (Each undeclared identifier is reported only once
> GetDflt.c:240: error: for each function it appears in.)
> make[3]: *** [GetDflt.lo] Error 1
That's weird - looks like your Xlib.h/Xlibint.h is desynced. Try
deleting include/Xlibint.h and seeing ... oh.
It's picking up Xlibint.h from somewhere else, maybe? If you have an
Xlibint.h somewhere else, delete it.
--
Daniel Stone <[email protected]>
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/20040629/5eb07765/attach
ment.pgp
From grifis87 at virgilio.it Mon Jun 28 13:23:26 2004
From: grifis87 at virgilio.it (Giovanni)
Date: Mon Jun 28 11:29:55 2004
Subject: [Xorg] debrix related: corrupted screen with nv
Message-ID: <[email protected]>
the server starts with no problem, mouse and keyboard is ok, it's stable, but
the screen looks corrupted and with fonts messed up...anyway I'm glad someone
is finally working on nvidia :)
From mfrey at pepper.com Mon Jun 28 11:31:45 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 11:31:50 2004
Subject: [Xorg] Error building X11
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
There is Xlibint.h in X11/include/X11 and when I delete it I can no
longer build.
[root@chawa freedesktop]# cd X11/
[root@chawa X11]# make
Making all in include
make[1]: Entering directory `/home/michael.frey/freedesktop/X11/include'
make[1]: *** No rule to make target `X11/Xlibint.h', needed by
`all-am'. Stop.
make[1]: Leaving directory `/home/michael.frey/freedesktop/X11/include'
make: *** [all-recursive] Error 1
I even tried to delete everything and start over. I use the build
script that is posted on the freedesktop website.
On Jun 28, 2004, at 2:16 PM, Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 02:06:50PM -0400, Michael Frey wrote:
>> I am trying to build the latest and I get the following build error
>> when building X11.
>>
>> xscale_le-gcc -DHAVE_CONFIG_H -I. -I. -I. -include config.h
>> -I../include -I../include/X11 -Wall -Wpointer-arith
>> -Wstrict-prototypes
>> -Wmissing-prototypes -Wmissing-declarations -Wnested-externs
>> -fno-strict-aliasing -D_BSD_SOURCE -I/opt/fdo/include
>> -I/opt/fdo/include/X11/Xtrans -D_XOPEN_SOURCE -I/opt/fdo/include
>> -DXTHREADS -DXUSE_MTSAFE_API -DX11_DATADIR=\"/opt/fdo/share/X11\" -g
>> -O2 -MT GetDflt.lo -MD -MP -MF .deps/GetDflt.Tpo -c GetDflt.c -fPIC
>> -DPIC -o .libs/GetDflt.o
>> GetDflt.c: In function `XGetDefault':
>> GetDflt.c:240: error: `XlibDispayDfltRMDB' undeclared (first use in
>> this function)
>> GetDflt.c:240: error: (Each undeclared identifier is reported only
>> once
>> GetDflt.c:240: error: for each function it appears in.)
>> make[3]: *** [GetDflt.lo] Error 1
>
> That's weird - looks like your Xlib.h/Xlibint.h is desynced. Try
> deleting include/Xlibint.h and seeing ... oh.
>
> It's picking up Xlibint.h from somewhere else, maybe? If you have an
> Xlibint.h somewhere else, delete it.
>
> --
> Daniel Stone
> <[email protected]>
> freedesktop.org: powering your desktop
> http://www.freedesktop.org
From daniel at freedesktop.org Mon Jun 28 11:32:24 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 11:32:27 2004
Subject: [Xorg] debrix related: corrupted screen with nv
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 08:23:26PM +0000, Giovanni wrote:
> the server starts with no problem, mouse and keyboard is ok, it's stable, but
> the screen looks corrupted and with fonts messed up...anyway I'm glad someone
> is finally working on nvidia :)
You're not building with --enable-composite, are you? If yes, disable it
- it's broken. If no, try with 'Option "NoAccel"'.
--
Daniel Stone <[email protected]>
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/20040629/99100537/attach
ment-0001.pgp
From daniel at freedesktop.org Mon Jun 28 11:33:14 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 11:33:16 2004
Subject: [Xorg] Error building X11
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 02:31:45PM -0400, Michael Frey wrote:
> There is Xlibint.h in X11/include/X11 and when I delete it I can no
> longer build.
Sorry, I meant everywhere but X11/include/X11. There's not one in
/usr/include or /opt/fdo/include or anything?
> [root@chawa freedesktop]# cd X11/
> [root@chawa X11]# make
> Making all in include
> make[1]: Entering directory `/home/michael.frey/freedesktop/X11/include'
> make[1]: *** No rule to make target `X11/Xlibint.h', needed by
> `all-am'. Stop.
> make[1]: Leaving directory `/home/michael.frey/freedesktop/X11/include'
> make: *** [all-recursive] Error 1
>
> I even tried to delete everything and start over. I use the build
> script that is posted on the freedesktop website.
That's weird - it seems to work fine here. X11/include/X11/Xlibint.h
should contain this define.
--
Daniel Stone <[email protected]>
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/20040629/54eddda0/attach
ment.pgp
From grifis87 at virgilio.it Mon Jun 28 13:32:34 2004
From: grifis87 at virgilio.it (Giovanni)
Date: Mon Jun 28 11:39:02 2004
Subject: [Xorg] debrix related: corrupted screen with nv
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Alle 18:32, luned? 28 giugno 2004, Daniel Stone ha scritto:
> On Mon, Jun 28, 2004 at 08:23:26PM +0000, Giovanni wrote:
> > the server starts with no problem, mouse and keyboard is ok, it's stable,
> > but the screen looks corrupted and with fonts messed up...anyway I'm glad
> > someone is finally working on nvidia :)
>
> You're not building with --enable-composite, are you? If yes, disable it
> - it's broken. If no, try with 'Option "NoAccel"'.
no, it wasn't with --enable-composite...i tried with that but i got this
error:
Making all in composite
make[1]: Entering directory `/home/giovanni/programmi/fdo/debrix/composite'
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../mi -I../Xext -I../render
-I../miext/damage -I../damageext -I../xfixes -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -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/include/X11/Xtrans
-I../hw/xorg/include -I../hw/xorg/common -I../hw/xorg/os-support -I../include
-I../os -I../hw/xorg/os-support/bus -I../Xext -I../Xi -I../render -I../randr
-I../xfixes -I../damageext -I../composite -I../mi -I../miext/damage

-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/include/X11/Xtrans
-I../Xi -DXF86CONFIGFILE=\"/opt/fdo/etc/xorg.conf\"
-DDEFAULT_MODULE_PATH=\"/opt/fdo/lib/xorg/modules/drivers\"
-DDEFAULT_LOGPREFIX=\"/opt/fdo/var/log/Xorg.\" -Wall -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wnested-externs -fno-strict-aliasing -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/include/X11/Xtrans -I../include
-I../Xext -g -O2 -MT compalloc.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/compalloc.Tpo"; exit 1; fi
compalloc.c: In function `compRedirectWindow':
compalloc.c:94: warning: passing arg 5 of `DamageCreate' from incompatible
pointer type
compalloc.c:94: error: too few arguments to function `DamageCreate'
make[1]: *** [compalloc.o] Error 1
make[1]: Leaving directory `/home/giovanni/programmi/fdo/debrix/composite'
make: *** [all-recursive] Error 1
anyway..it works with Option "NoAccel" :)
From mfrey at pepper.com Mon Jun 28 11:40:17 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 11:40:22 2004
Subject: [Xorg] Error building X11
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
I do not have Xlibint.h any where else.
I have attached Xlibint.h from the X11/include/X11 dir. Does this file
get generated?
-------------- next part --------------
/* $Xorg: Xlibint.h,v 1.5 2001/02/09 02:03:38 xorgcvs Exp $ */
/*
Copyright 1984, 1985, 1987, 1989, 1998 The Open Group
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation.
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of The Open Group shall
not be used in advertising or otherwise to promote the sale, use or
other dealings in this Software without prior written authorization
from The Open Group.
*/
/* $XFree86: xc/lib/X11/Xlibint.h,v 3.28 2003/11/17 22:20:11 dawes Exp $ */
#ifndef _XLIBINT_H_
#define _XLIBINT_H_ 1
/*
* Xlibint.h - Header definition and support file for the internal
* support routines used by the C subroutine interface
* library (Xlib) to the X Window System.
*
* Warning, there be dragons here....
*/
#include <X11/Xlib.h>
#include <X11/Xproto.h> /* to declare xEvent */
#ifdef WIN32
#define _XFlush _XFlushIt
#endif
/*
* If your BytesReadable correctly detects broken connections, then
* you should NOT define XCONN_CHECK_FREQ.
*/
#ifndef XCONN_CHECK_FREQ
#define XCONN_CHECK_FREQ 256
#endif
struct _XGC
{
XExtData *ext_data; /* hook for extension to hang data */
GContext gid; /* protocol ID for graphics context */
Bool rects; /* boolean: TRUE if clipmask is list of rectangles */
Bool dashes; /* boolean: TRUE if dash-list is really a list */
unsigned long dirty;/* cache dirty bits */
XGCValues values; /* shadow structure of values */
};
struct _XDisplay
{
XExtData *ext_data; /* hook for extension to hang data */
struct _XFreeFuncs *free_funcs; /* internal free functions */
int fd; /* Network socket. */
int conn_checker; /* ugly thing used by _XEventsQueued */
int proto_major_version;/* maj. version of server's X protocol */
int proto_minor_version;/* minor version of server's X protocol */
char *vendor; /* vendor of the server hardware */
XID resource_base; /* resource ID base */
XID resource_mask; /* resource ID mask bits */
XID resource_id; /* allocator current ID */
int resource_shift; /* allocator shift to correct bits */
XID (*resource_alloc)( /* allocator function */
struct _XDisplay*
);
int byte_order; /* screen byte order, LSBFirst, MSBFirst */
int bitmap_unit; /* padding and data requirements */
int bitmap_pad; /* padding requirements on bitmaps */
int bitmap_bit_order; /* LeastSignificant or MostSignificant */
int nformats; /* number of pixmap formats in list */
ScreenFormat *pixmap_format; /* pixmap format list */
int vnumber; /* Xlib's X protocol version number. */
int release; /* release of the server */
struct _XSQEvent *head, *tail; /* Input event queue. */
int qlen; /* Length of input event queue */
unsigned long last_request_read; /* seq number of last event read */
unsigned long request; /* sequence number of last request. */
char *last_req; /* beginning of last request, or dummy */
char *buffer; /* Output buffer starting address. */
char *bufptr; /* Output buffer index pointer. */
char *bufmax; /* Output buffer maximum+1 address. */
unsigned max_request_size; /* maximum number 32 bit words in request*/
struct _XrmHashBucketRec *db;
int (*synchandler)( /* Synchronization handler */
struct _XDisplay*
);
char *display_name; /* "host:display" string used on this connect*/
int default_screen; /* default screen for operations */
int nscreens; /* number of screens on this server*/
Screen *screens; /* pointer to list of screens */
unsigned long motion_buffer; /* size of motion buffer */
unsigned long flags; /* internal connection flags */
int min_keycode; /* minimum defined keycode */
int max_keycode; /* maximum defined keycode */
KeySym *keysyms; /* This server's keysyms */
XModifierKeymap *modifiermap; /* This server's modifier keymap */
int keysyms_per_keycode;/* number of rows */
char *xdefaults; /* contents of defaults from server */
char *scratch_buffer; /* place to hang scratch buffer */
unsigned long scratch_length; /* length of scratch buffer */
int ext_number; /* extension number on this display */
struct _XExten *ext_procs; /* extensions initialized on this display */
/*
* the following can be fixed size, as the protocol defines how
* much address space is available.
* While this could be done using the extension vector, there
* may be MANY events processed, so a search through the extension
* list to find the right procedure for each event might be
* expensive if many extensions are being used.
*/
Bool (*event_vec[128])( /* vector for wire to event */
Display * /* dpy */,
XEvent * /* re */,
xEvent * /* event */
);
Status (*wire_vec[128])( /* vector for event to wire */
Display * /* dpy */,
XEvent * /* re */,
xEvent * /* event */
);
KeySym lock_meaning; /* for XLookupString */
struct _XLockInfo *lock; /* multi-thread state, display lock */
struct _XInternalAsync *async_handlers; /* for internal async */
unsigned long bigreq_size; /* max size of big requests */
struct _XLockPtrs *lock_fns; /* pointers to threads functions */
void (*idlist_alloc)( /* XID list allocator function */
Display * /* dpy */,
XID * /* ids */,
int /* count */
);
/* things above this line should not move, for binary compatibility */
struct _XKeytrans *key_bindings; /* for XLookupString */
Font cursor_font; /* for XCreateFontCursor */
struct _XDisplayAtoms *atoms; /* for XInternAtom */
unsigned int mode_switch; /* keyboard group modifiers */
unsigned int num_lock; /* keyboard numlock modifiers */
struct _XContextDB *context_db; /* context database */
Bool (**error_vec)( /* vector for wire to error */
Display * /* display */,
XErrorEvent * /* he */,
xError * /* we */
);
/*
* Xcms information
*/
struct {
XPointer defaultCCCs; /* pointer to an array of default XcmsCCC */
XPointer clientCmaps; /* pointer to linked list of XcmsCmapRec */
XPointer perVisualIntensityMaps;
/* linked list of XcmsIntensityMap */
} cms;
struct _XIMFilter *im_filters;
struct _XSQEvent *qfree; /* unallocated event queue elements */
unsigned long next_event_serial_num; /* inserted into next queue elt */
struct _XExten *flushes; /* Flush hooks */
struct _XConnectionInfo *im_fd_info; /* _XRegisterInternalConnection */
int im_fd_length; /* number of im_fd_info */
struct _XConnWatchInfo *conn_watchers; /* XAddConnectionWatch */
int watcher_count; /* number of conn_watchers */
XPointer filedes; /* struct pollfd cache for _XWaitForReadable */
int (*savedsynchandler)( /* user synchandler when Xlib usurps */
Display * /* dpy */
);
XID resource_max; /* allocator max ID */
int xcmisc_opcode; /* major opcode for XC-MISC */
struct _XkbInfoRec *xkb_info; /* XKB info */
struct _XtransConnInfo *trans_conn; /* transport connection object */
#if USE_XCB
struct XCLPrivate *xcl; /* XCB glue private data */
#endif
};
#define XAllocIDs(dpy,ids,n) (*(dpy)->idlist_alloc)(dpy,ids,n)
/*
* define the following if you want the Data macro to be a procedure instead
*/
#ifdef CRAY
#define DataRoutineIsProcedure
#endif /* CRAY */
#ifndef _XEVENT_
/*
* _QEvent datatype for use in input queueing.
*/
typedef struct _XSQEvent
{
struct _XSQEvent *next;
XEvent event;
unsigned long qserial_num; /* so multi-threaded code can find new ones */
} _XQEvent;
#endif
#ifdef XTHREADS /* for xReply */
#define NEED_REPLIES
#endif
#define NEED_EVENTS
#define NEED_REPLIES
#include <X11/Xproto.h>
#ifdef __sgi
#define _SGI_MP_SOURCE /* turn this on to get MP safe errno */
#endif
#include <errno.h>
#define _XBCOPYFUNC _Xbcopy
#include <X11/Xfuncs.h>
#include <X11/Xosdefs.h>
/* Utek leaves kernel macros around in include files (bleah) */
#ifdef dirty
#undef dirty
#endif
#include <stdlib.h>
#include <string.h>
#include <X11/Xfuncproto.h>
_XFUNCPROTOBEGIN
/*
* The following definitions can be used for locking requests in multi-threaded
* address spaces.
*/
#ifdef XTHREADS
/* Author: Stephen Gildea, MIT X Consortium
*
* declarations for C Threads locking
*/
typedef struct _LockInfoRec *LockInfoPtr;
/* interfaces for locking.c */
struct _XLockPtrs {
/* used by all, including extensions; do not move */
void (*lock_display)(
Display *dpy
#if defined(XTHREADS_WARN) || defined(XTHREADS_FILE_LINE)
, char *file
, int line
#endif
);
void (*unlock_display)(
Display *dpy
#if defined(XTHREADS_WARN) || defined(XTHREADS_FILE_LINE)
, char *file
, int line
#endif
);
};
#if defined(WIN32) && !defined(_XLIBINT_)
#define _XCreateMutex_fn (*_XCreateMutex_fn_p)
#define _XFreeMutex_fn (*_XFreeMutex_fn_p)
#define _XLockMutex_fn (*_XLockMutex_fn_p)
#define _XUnlockMutex_fn (*_XUnlockMutex_fn_p)
#define _Xglobal_lock (*_Xglobal_lock_p)
#endif
/* in XlibInt.c */
extern void (*_XCreateMutex_fn)(
LockInfoPtr /* lock */
);
extern void (*_XFreeMutex_fn)(
LockInfoPtr /* lock */
);
extern void (*_XLockMutex_fn)(
LockInfoPtr /* lock */
#if defined(XTHREADS_WARN) || defined(XTHREADS_FILE_LINE)
, char * /* file */
, int /* line */
#endif
);
extern void (*_XUnlockMutex_fn)(
LockInfoPtr /* lock */
#if defined(XTHREADS_WARN) || defined(XTHREADS_FILE_LINE)
, char * /* file */
, int /* line */
#endif
);
extern LockInfoPtr _Xglobal_lock;
#if defined(XTHREADS_WARN) || defined(XTHREADS_FILE_LINE)
#define LockDisplay(d) if ((d)->lock_fns) (*(d)->lock_fns->lock_display)((
d),__FILE__,__LINE__)
#define UnlockDisplay(d) if ((d)->lock_fns) (*(d)->lock_fns->unlock_display)
((d),__FILE__,__LINE__)
#define _XLockMutex(lock) if (_XLockMutex_fn) (*_XLockMutex_fn)(lo
ck,__FILE__,__LINE__)
#define _XUnlockMutex(lock) if (_XUnlockMutex_fn) (*_XUnlockMutex_fn)(lock,_
_FILE__,__LINE__)
#else
/* used everywhere, so must be fast if not using threads */
#define LockDisplay(d) if ((d)->lock_fns) (*(d)->lock_fns->lock_display)(d
)
#define UnlockDisplay(d) if ((d)->lock_fns) (*(d)->lock_fns->unlock_display)
(d)
#define _XLockMutex(lock) if (_XLockMutex_fn) (*_XLockMutex_fn)(lo
ck)
#define _XUnlockMutex(lock) if (_XUnlockMutex_fn) (*_XUnlockMutex_fn)(lock)
#endif
#define _XCreateMutex(lock) if (_XCreateMutex_fn) (*_XCreateMutex_fn)(lock);
#define _XFreeMutex(lock) if (_XFreeMutex_fn) (*_XFreeMutex_fn)(lock);
#else /* XTHREADS */
#define LockDisplay(dis)
#define _XLockMutex(lock)
#define _XUnlockMutex(lock)
#define UnlockDisplay(dis)
#define _XCreateMutex(lock)
#define _XFreeMutex(lock)
#endif
#define Xfree(ptr) free((ptr))
/*
* Note that some machines do not return a valid pointer for malloc(0), in
* which case we provide an alternate under the control of the
* define MALLOC_0_RETURNS_NULL. This is necessary because some
* Xlib code expects malloc(0) to return a valid pointer to storage.
*/
#ifdef MALLOC_0_RETURNS_NULL
# define Xmalloc(size) malloc(((size) == 0 ? 1 : (size)))
# define Xrealloc(ptr, size) realloc((ptr), ((size) == 0 ? 1 : (size)))
# define Xcalloc(nelem, elsize) calloc(((nelem) == 0 ? 1 : (nelem)), (elsize))
#else
# define Xmalloc(size) malloc((size))
# define Xrealloc(ptr, size) realloc((ptr), (size))
# define Xcalloc(nelem, elsize) calloc((nelem), (elsize))
#endif
#include <stddef.h>
#define LOCKED 1
#define UNLOCKED 0
#ifndef BUFSIZE
#define BUFSIZE 2048 /* X output buffer size. */
#endif
#ifndef PTSPERBATCH
#define PTSPERBATCH 1024 /* point batching */
#endif
#ifndef WLNSPERBATCH
#define WLNSPERBATCH 50 /* wide line batching */
#endif
#ifndef ZLNSPERBATCH
#define ZLNSPERBATCH 1024 /* thin line batching */
#endif
#ifndef WRCTSPERBATCH
#define WRCTSPERBATCH 10 /* wide line rectangle batching */
#endif
#ifndef ZRCTSPERBATCH
#define ZRCTSPERBATCH 256 /* thin line rectangle batching */
#endif
#ifndef FRCTSPERBATCH
#define FRCTSPERBATCH 256 /* filled rectangle batching */
#endif
#ifndef FARCSPERBATCH
#define FARCSPERBATCH 256 /* filled arc batching */
#endif
#ifndef CURSORFONT
#define CURSORFONT "cursor" /* standard cursor fonts */
#endif
/*
* Display flags
*/
#define XlibDisplayIOError (1L << 0)
#define XlibDisplayClosing (1L << 1)
#define XlibDisplayNoXkb (1L << 2)
#define XlibDisplayPrivSync (1L << 3)
#define XlibDisplayProcConni (1L << 4) /* in _XProcessInternalConnection */
#define XlibDisplayReadEvents (1L << 5) /* in _XReadEvents */
#define XlibDisplayReply (1L << 5) /* in _XReply */
#define XlibDisplayWriting (1L << 6) /* in _XFlushInt, _XSend */
#define XlibDisplayDfltRMDB (1L << 7) /* mark if RM db from XGetDefault */
/*
* X Protocol packetizing macros.
*/
/* Need to start requests on 64 bit word boundaries
* on a CRAY computer so add a NoOp (127) if needed.
* A character pointer on a CRAY computer will be non-zero
* after shifting right 61 bits of it is not pointing to
* a word boundary.
*/
#ifdef WORD64
#define WORD64ALIGN if ((long)dpy->bufptr >> 61) {\
dpy->last_req = dpy->bufptr;\
*(dpy->bufptr) = X_NoOperation;\
*(dpy->bufptr+1) = 0;\
*(dpy->bufptr+2) = 0;\
*(dpy->bufptr+3) = 1;\
dpy->request++;\
dpy->bufptr += 4;\
}
#else /* else does not require alignment on 64-bit boundaries */
#define WORD64ALIGN
#endif /* WORD64 */
/*
* GetReq - Get the next available X request packet in the buffer and
* return it.
*
* "name" is the name of the request, e.g. CreatePixmap, OpenFont, etc.
* "req" is the name of the request pointer.
*
*/
#if !defined(UNIXCPP) || defined(ANSICPP)
#define GetReq(name, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(x##name##Req)) > dpy->bufmax)\
_XFlush(dpy);\
req = (x##name##Req *)(dpy->last_req = dpy->bufptr);\
req->reqType = X_##name;\
req->length = (SIZEOF(x##name##Req))>>2;\
dpy->bufptr += SIZEOF(x##name##Req);\
dpy->request++
#else /* non-ANSI C uses empty comment instead of "##" for token concatenation
*/
#define GetReq(name, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(x/**/name/**/Req)) > dpy->bufmax)\
_XFlush(dpy);\
req = (x/**/name/**/Req *)(dpy->last_req = dpy->bufptr);\
req->reqType = X_/**/name;\
req->length = (SIZEOF(x/**/name/**/Req))>>2;\
dpy->bufptr += SIZEOF(x/**/name/**/Req);\
dpy->request++
#endif
/* GetReqExtra is the same as GetReq, but allocates "n" additional
bytes after the request. "n" must be a multiple of 4! */
#if !defined(UNIXCPP) || defined(ANSICPP)
#define GetReqExtra(name, n, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(x##name##Req) + n) > dpy->bufmax)\
_XFlush(dpy);\
req = (x##name##Req *)(dpy->last_req = dpy->bufptr);\
req->reqType = X_##name;\
req->length = (SIZEOF(x##name##Req) + n)>>2;\
dpy->bufptr += SIZEOF(x##name##Req) + n;\
dpy->request++
#else
#define GetReqExtra(name, n, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(x/**/name/**/Req) + n) > dpy->bufmax)\
_XFlush(dpy);\
req = (x/**/name/**/Req *)(dpy->last_req = dpy->bufptr);\
req->reqType = X_/**/name;\
req->length = (SIZEOF(x/**/name/**/Req) + n)>>2;\
dpy->bufptr += SIZEOF(x/**/name/**/Req) + n;\
dpy->request++
#endif
/*
* GetResReq is for those requests that have a resource ID
* (Window, Pixmap, GContext, etc.) as their single argument.
* "rid" is the name of the resource.
*/
#if !defined(UNIXCPP) || defined(ANSICPP)
#define GetResReq(name, rid, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(xResourceReq)) > dpy->bufmax)\
_XFlush(dpy);\
req = (xResourceReq *) (dpy->last_req = dpy->bufptr);\
req->reqType = X_##name;\
req->length = 2;\
req->id = (rid);\
dpy->bufptr += SIZEOF(xResourceReq);\
dpy->request++
#else
#define GetResReq(name, rid, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(xResourceReq)) > dpy->bufmax)\
_XFlush(dpy);\
req = (xResourceReq *) (dpy->last_req = dpy->bufptr);\
req->reqType = X_/**/name;\
req->length = 2;\
req->id = (rid);\
dpy->bufptr += SIZEOF(xResourceReq);\
dpy->request++
#endif
/*
* GetEmptyReq is for those requests that have no arguments
* at all.
*/
#if !defined(UNIXCPP) || defined(ANSICPP)
#define GetEmptyReq(name, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(xReq)) > dpy->bufmax)\
_XFlush(dpy);\
req = (xReq *) (dpy->last_req = dpy->bufptr);\
req->reqType = X_##name;\
req->length = 1;\
dpy->bufptr += SIZEOF(xReq);\
dpy->request++
#else
#define GetEmptyReq(name, req) \
WORD64ALIGN\
if ((dpy->bufptr + SIZEOF(xReq)) > dpy->bufmax)\
_XFlush(dpy);\
req = (xReq *) (dpy->last_req = dpy->bufptr);\
req->reqType = X_/**/name;\
req->length = 1;\
dpy->bufptr += SIZEOF(xReq);\
dpy->request++
#endif
#ifdef WORD64
#define MakeBigReq(req,n) \
{ \
char _BRdat[4]; \
unsigned long _BRlen = req->length - 1; \
req->length = 0; \
memcpy(_BRdat, ((char *)req) + (_BRlen << 2), 4); \
memmove(((char *)req) + 8, ((char *)req) + 4, _BRlen << 2); \
memcpy(((char *)req) + 4, _BRdat, 4); \
Data32(dpy, (long *)&_BRdat, 4); \
}
#else
#ifdef LONG64
#define MakeBigReq(req,n) \
{ \
CARD64 _BRdat; \
CARD32 _BRlen = req->length - 1; \
req->length = 0; \
_BRdat = ((CARD32 *)req)[_BRlen]; \
memmove(((char *)req) + 8, ((char *)req) + 4, _BRlen << 2); \
((CARD32 *)req)[1] = _BRlen + n + 2; \
Data32(dpy, &_BRdat, 4); \
}
#else
#define MakeBigReq(req,n) \
{ \
CARD32 _BRdat; \
CARD32 _BRlen = req->length - 1; \
req->length = 0; \
_BRdat = ((CARD32 *)req)[_BRlen]; \
memmove(((char *)req) + 8, ((char *)req) + 4, _BRlen << 2); \
((CARD32 *)req)[1] = _BRlen + n + 2; \
Data32(dpy, &_BRdat, 4); \
}
#endif
#endif
#define SetReqLen(req,n,badlen) \
if ((req->length + n) > (unsigned)65535) { \
if (dpy->bigreq_size) { \
MakeBigReq(req,n) \
} else { \
n = badlen; \
req->length += n; \
} \
} else \
req->length += n
#define SyncHandle() \
if (dpy->synchandler) (*dpy->synchandler)(dpy)
extern void _XFlushGCCache(Display *dpy, GC gc);
#define FlushGC(dpy, gc) \
if ((gc)->dirty) _XFlushGCCache((dpy), (gc))
/*
* Data - Place data in the buffer and pad the end to provide
* 32 bit word alignment. Transmit if the buffer fills.
*
* "dpy" is a pointer to a Display.
* "data" is a pinter to a data buffer.
* "len" is the length of the data buffer.
*/
#ifndef DataRoutineIsProcedure
#define Data(dpy, data, len) {\
if (dpy->bufptr + (len) <= dpy->bufmax) {\
memcpy(dpy->bufptr, data, (int)len);\
dpy->bufptr += ((len) + 3) & ~3;\
} else\
_XSend(dpy, data, len);\
}
#endif /* DataRoutineIsProcedure */
/* Allocate bytes from the buffer. No padding is done, so if
* the length is not a multiple of 4, the caller must be
* careful to leave the buffer aligned after sending the
* current request.
*
* "type" is the type of the pointer being assigned to.
* "ptr" is the pointer being assigned to.
* "n" is the number of bytes to allocate.
*
* Example:
* xTextElt *elt;
* BufAlloc (xTextElt *, elt, nbytes)
*/
#define BufAlloc(type, ptr, n) \
if (dpy->bufptr + (n) > dpy->bufmax) \
_XFlush (dpy); \
ptr = (type) dpy->bufptr; \
(void)ptr; \
dpy->bufptr += (n);
#ifdef WORD64
#define Data16(dpy, data, len) _XData16(dpy, (short *)data, len)
#define Data32(dpy, data, len) _XData32(dpy, (long *)data, len)
#else
#define Data16(dpy, data, len) Data((dpy), (char *)(data), (len))
#define _XRead16Pad(dpy, data, len) _XReadPad((dpy), (char *)(data), (len))
#define _XRead16(dpy, data, len) _XRead((dpy), (char *)(data), (len))
#ifdef LONG64
#define Data32(dpy, data, len) _XData32(dpy, (long *)data, len)
extern int _XData32(
Display *dpy,
register long *data,
unsigned len
);
extern void _XRead32(
Display *dpy,
register long *data,
long len
);
#else
#define Data32(dpy, data, len) Data((dpy), (char *)(data), (len))
#define _XRead32(dpy, data, len) _XRead((dpy), (char *)(data), (len))
#endif
#endif /* not WORD64 */
#define PackData16(dpy,data,len) Data16 (dpy, data, len)
#define PackData32(dpy,data,len) Data32 (dpy, data, len)
/* Xlib manual is bogus */
#define PackData(dpy,data,len) PackData16 (dpy, data, len)
#define min(a,b) (((a) < (b)) ? (a) : (b))
#define max(a,b) (((a) > (b)) ? (a) : (b))
#define CI_NONEXISTCHAR(cs) (((cs)->width == 0) && \
(((cs)->rbearing|(cs)->lbearing| \
(cs)->ascent|(cs)->descent) == 0))
/*
* CI_GET_CHAR_INFO_1D - return the charinfo struct for the indicated 8bit
* character. If the character is in the column and exists, then return the
* appropriate metrics (note that fonts with common per-character metrics will
* return min_bounds). If none of these hold true, try again with the default
* char.
*/
#define CI_GET_CHAR_INFO_1D(fs,col,def,cs) \
{ \
cs = def; \
if (col >= fs->min_char_or_byte2 && col <= fs->max_char_or_byte2) { \
if (fs->per_char == NULL) { \
cs = &fs->min_bounds; \
} else { \
cs = &fs->per_char[(col - fs->min_char_or_byte2)]; \
if (CI_NONEXISTCHAR(cs)) cs = def; \
} \
} \
}
#define CI_GET_DEFAULT_INFO_1D(fs,cs) \
CI_GET_CHAR_INFO_1D (fs, fs->default_char, NULL, cs)
/*
* CI_GET_CHAR_INFO_2D - return the charinfo struct for the indicated row and
* column. This is used for fonts that have more than row zero.
*/
#define CI_GET_CHAR_INFO_2D(fs,row,col,def,cs) \
{ \
cs = def; \
if (row >= fs->min_byte1 && row <= fs->max_byte1 && \
col >= fs->min_char_or_byte2 && col <= fs->max_char_or_byte2) { \
if (fs->per_char == NULL) { \
cs = &fs->min_bounds; \
} else { \
cs = &fs->per_char[((row - fs->min_byte1) * \
(fs->max_char_or_byte2 - \
fs->min_char_or_byte2 + 1)) + \
(col - fs->min_char_or_byte2)]; \
if (CI_NONEXISTCHAR(cs)) cs = def; \
} \
} \
}
#define CI_GET_DEFAULT_INFO_2D(fs,cs) \
{ \
unsigned int r = (fs->default_char >> 8); \
unsigned int c = (fs->default_char & 0xff); \
CI_GET_CHAR_INFO_2D (fs, r, c, NULL, cs); \
}
#ifdef MUSTCOPY
/* for when 32-bit alignment is not good enough */
#define OneDataCard32(dpy,dstaddr,srcvar) \
{ dpy->bufptr -= 4; Data32 (dpy, (char *) &(srcvar), 4); }
#else
/* srcvar must be a variable for large architecture version */
#define OneDataCard32(dpy,dstaddr,srcvar) \
{ *(CARD32 *)(dstaddr) = (srcvar); }
#endif /* MUSTCOPY */
typedef struct _XInternalAsync {
struct _XInternalAsync *next;
/*
* handler arguments:
* rep is the generic reply that caused this handler
* to be invoked. It must also be passed to _XGetAsyncReply.
* buf and len are opaque values that must be passed to
* _XGetAsyncReply or _XGetAsyncData.
* data is the closure stored in this struct.
* The handler returns True iff it handled this reply.
*/
Bool (*handler)(
Display* /* dpy */,
xReply* /* rep */,
char* /* buf */,
int /* len */,
XPointer /* data */
);
XPointer data;
} _XAsyncHandler;
typedef struct _XAsyncEState {
unsigned long min_sequence_number;
unsigned long max_sequence_number;
unsigned char error_code;
unsigned char major_opcode;
unsigned short minor_opcode;
unsigned char last_error_received;
int error_count;
} _XAsyncErrorState;
extern void _XDeqAsyncHandler(Display *dpy, _XAsyncHandler *handler);
#define DeqAsyncHandler(dpy,handler) { \
if (dpy->async_handlers == (handler)) \
dpy->async_handlers = (handler)->next; \
else \
_XDeqAsyncHandler(dpy, handler); \
}
typedef void (*FreeFuncType) (
Display* /* display */
);
typedef int (*FreeModmapType) (
XModifierKeymap* /* modmap */
);
/*
* This structure is private to the library.
*/
typedef struct _XFreeFuncs {
FreeFuncType atoms; /* _XFreeAtomTable */
FreeModmapType modifiermap; /* XFreeModifierMap */
FreeFuncType key_bindings; /* _XFreeKeyBindings */
FreeFuncType context_db; /* _XFreeContextDB */
FreeFuncType defaultCCCs; /* _XcmsFreeDefaultCCCs */
FreeFuncType clientCmaps; /* _XcmsFreeClientCmaps */
FreeFuncType intensityMaps; /* _XcmsFreeIntensityMaps */
FreeFuncType im_filters; /* _XFreeIMFilters */
FreeFuncType xkb; /* _XkbFreeInfo */
} _XFreeFuncRec;
/* types for InitExt.c */
typedef int (*CreateGCType) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
);
typedef int (*CopyGCType)(
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
);
typedef int (*FlushGCType) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
);
typedef int (*FreeGCType) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
);
typedef int (*CreateFontType) (
Display* /* display */,
XFontStruct* /* fs */,
XExtCodes* /* codes */
);
typedef int (*FreeFontType) (
Display* /* display */,
XFontStruct* /* fs */,
XExtCodes* /* codes */
);
typedef int (*CloseDisplayType) (
Display* /* display */,
XExtCodes* /* codes */
);
typedef int (*ErrorType) (
Display* /* display */,
xError* /* err */,
XExtCodes* /* codes */,
int* /* ret_code */
);
typedef char* (*ErrorStringType) (
Display* /* display */,
int /* code */,
XExtCodes* /* codes */,
char* /* buffer */,
int /* nbytes */
);
typedef void (*PrintErrorType)(
Display* /* display */,
XErrorEvent* /* ev */,
void* /* fp */
);
typedef void (*BeforeFlushType)(
Display* /* display */,
XExtCodes* /* codes */,
_Xconst char* /* data */,
long /* len */
);
/*
* This structure is private to the library.
*/
typedef struct _XExten { /* private to extension mechanism */
struct _XExten *next; /* next in list */
XExtCodes codes; /* public information, all extension tol
d */
CreateGCType create_GC; /* routine to call when GC created */
CopyGCType copy_GC; /* routine to call when GC copied */
FlushGCType flush_GC; /* routine to call when GC flushed */
FreeGCType free_GC; /* routine to call when GC freed */
CreateFontType create_Font; /* routine to call when Font created */
FreeFontType free_Font; /* routine to call when Font freed */
CloseDisplayType close_display; /* routine to call when connection close
d */
ErrorType error; /* who to call when an error occurs */
ErrorStringType error_string; /* routine to supply error string */
char *name; /* name of this extension */
PrintErrorType error_values; /* routine to supply error values */
BeforeFlushType before_flush; /* routine to call when sending data */
struct _XExten *next_flush; /* next in list of those with flushes */
} _XExtension;
/* extension hooks */
#ifdef DataRoutineIsProcedure
extern void Data(Display *dpy, char *data, long len);
#endif
extern int _XError(
Display* /* dpy */,
xError* /* rep */
);
extern int _XIOError(
Display* /* dpy */
);
extern int (*_XIOErrorFunction)(
Display* /* dpy */
);
extern int (*_XErrorFunction)(
Display* /* dpy */,
XErrorEvent* /* error_event */
);
extern void _XEatData(
Display* /* dpy */,
unsigned long /* n */
);
extern char *_XAllocScratch(
Display* /* dpy */,
unsigned long /* nbytes */
);
extern char *_XAllocTemp(
Display* /* dpy */,
unsigned long /* nbytes */
);
extern void _XFreeTemp(
Display* /* dpy */,
char* /* buf */,
unsigned long /* nbytes */
);
extern Visual *_XVIDtoVisual(
Display* /* dpy */,
VisualID /* id */
);
extern unsigned long _XSetLastRequestRead(
Display* /* dpy */,
xGenericReply* /* rep */
);
extern int _XGetHostname(
char* /* buf */,
int /* maxlen */
);
extern Screen *_XScreenOfWindow(
Display* /* dpy */,
Window /* w */
);
extern Bool _XAsyncErrorHandler(
Display* /* dpy */,
xReply* /* rep */,
char* /* buf */,
int /* len */,
XPointer /* data */
);
extern char *_XGetAsyncReply(
Display* /* dpy */,
char* /* replbuf */,
xReply* /* rep */,
char* /* buf */,
int /* len */,
int /* extra */,
Bool /* discard */
);
extern void _XGetAsyncData(
Display* /* dpy */,
char * /* data */,
char * /* buf */,
int /* len */,
int /* skip */,
int /* datalen */,
int /* discardtotal */
);
extern void _XFlush(
Display* /* dpy */
);
extern int _XEventsQueued(
Display* /* dpy */,
int /* mode */
);
extern void _XReadEvents(
Display* /* dpy */
);
extern int _XRead(
Display* /* dpy */,
char* /* data */,
long /* size */
);
extern void _XReadPad(
Display* /* dpy */,
char* /* data */,
long /* size */
);
extern void _XSend(
Display* /* dpy */,
_Xconst char* /* data */,
long /* size */
);
extern Status _XReply(
Display* /* dpy */,
xReply* /* rep */,
int /* extra */,
Bool /* discard */
);
extern void _XEnq(
Display* /* dpy */,
xEvent* /* event */
);
extern void _XDeq(
Display* /* dpy */,
_XQEvent* /* prev */,
_XQEvent* /* qelt */
);
extern Bool _XUnknownWireEvent(
Display* /* dpy */,
XEvent* /* re */,
xEvent* /* event */
);
extern Status _XUnknownNativeEvent(
Display* /* dpy */,
XEvent* /* re */,
xEvent* /* event */
);
extern Bool _XWireToEvent(Display *dpy, XEvent *re, xEvent *event);
extern Bool _XDefaultWireError(Display *display, XErrorEvent *he, xError *we);
extern Bool _XPollfdCacheInit(Display *dpy);
extern void _XPollfdCacheAdd(Display *dpy, int fd);
extern void _XPollfdCacheDel(Display *dpy, int fd);
extern XID _XAllocID(Display *dpy);
extern void _XAllocIDs(Display *dpy, XID *ids, int count);
extern int _XFreeExtData(
XExtData* /* extension */
);
extern int (*XESetCreateGC(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, GC, XExtCodes*
);
extern int (*XESetCopyGC(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, GC, XExtCodes*
);
extern int (*XESetFlushGC(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, GC, XExtCodes*
);
extern int (*XESetFreeGC(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
GC /* gc */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, GC, XExtCodes*
);
extern int (*XESetCreateFont(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
XFontStruct* /* fs */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, XFontStruct*, XExtCodes*
);
extern int (*XESetFreeFont(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
XFontStruct* /* fs */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, XFontStruct*, XExtCodes*
);
extern int (*XESetCloseDisplay(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
XExtCodes* /* codes */
) /* proc */
))(
Display*, XExtCodes*
);
extern int (*XESetError(
Display* /* display */,
int /* extension */,
int (*) (
Display* /* display */,
xError* /* err */,
XExtCodes* /* codes */,
int* /* ret_code */
) /* proc */
))(
Display*, xError*, XExtCodes*, int*
);
extern char* (*XESetErrorString(
Display* /* display */,
int /* extension */,
char* (*) (
Display* /* display */,
int /* code */,
XExtCodes* /* codes */,
char* /* buffer */,
int /* nbytes */
) /* proc */
))(
Display*, int, XExtCodes*, char*, int
);
extern void (*XESetPrintErrorValues (
Display* /* display */,
int /* extension */,
void (*)(
Display* /* display */,
XErrorEvent* /* ev */,
void* /* fp */
) /* proc */
))(
Display*, XErrorEvent*, void*
);
extern Bool (*XESetWireToEvent(
Display* /* display */,
int /* event_number */,
Bool (*) (
Display* /* display */,
XEvent* /* re */,
xEvent* /* event */
) /* proc */
))(
Display*, XEvent*, xEvent*
);
extern Status (*XESetEventToWire(
Display* /* display */,
int /* event_number */,
Status (*) (
Display* /* display */,
XEvent* /* re */,
xEvent* /* event */
) /* proc */
))(
Display*, XEvent*, xEvent*
);
extern Bool (*XESetWireToError(
Display* /* display */,
int /* error_number */,
Bool (*) (
Display* /* display */,
XErrorEvent* /* he */,
xError* /* we */
) /* proc */
))(
Display*, XErrorEvent*, xError*
);
extern void (*XESetBeforeFlush(
Display* /* display */,
int /* error_number */,
void (*) (
Display* /* display */,
XExtCodes* /* codes */,
_Xconst char* /* data */,
long /* len */
) /* proc */
))(
Display*, XExtCodes*, _Xconst char*, long
);
/* internal connections for IMs */
typedef void (*_XInternalConnectionProc)(
Display* /* dpy */,
int /* fd */,
XPointer /* call_data */
);
extern Status _XRegisterInternalConnection(
Display* /* dpy */,
int /* fd */,
_XInternalConnectionProc /* callback */,
XPointer /* call_data */
);
extern void _XUnregisterInternalConnection(
Display* /* dpy */,
int /* fd */
);
/* Display structure has pointers to these */
struct _XConnectionInfo { /* info from _XRegisterInternalConnection */
int fd;
_XInternalConnectionProc read_callback;
XPointer call_data;
XPointer *watch_data; /* set/used by XConnectionWatchProc */
struct _XConnectionInfo *next;
};
struct _XConnWatchInfo { /* info from XAddConnectionWatch */
XConnectionWatchProc fn;
XPointer client_data;
struct _XConnWatchInfo *next;
};
#ifdef __UNIXOS2__
extern char* __XOS2RedirRoot(
char*
);
#endif
extern int _XTextHeight(
XFontStruct* /* font_struct */,
_Xconst char* /* string */,
int /* count */
);
extern int _XTextHeight16(
XFontStruct* /* font_struct */,
_Xconst XChar2b* /* string */,
int /* count */
);
#if defined(WIN32)
extern int _XOpenFile(
_Xconst char* /* path */,
int /* flags */
);
extern void* _XFopenFile(
_Xconst char* /* path */,
_Xconst char* /* mode */
);
extern int _XAccessFile(
_Xconst char* /* path */
);
#else
#define _XOpenFile(path,flags) open(path,flags)
#define _XFopenFile(path,mode) fopen(path,mode)
#endif
/* EvToWire.c */
extern Status _XEventToWire(Display *dpy, XEvent *re, xEvent *event);
extern int _XF86LoadQueryLocaleFont(
Display* /* dpy */,
_Xconst char* /* name*/,
XFontStruct** /* xfp*/,
Font* /* fidp */
);
extern void _XProcessWindowAttributes (
register Display *dpy,
xChangeWindowAttributesReq *req,
register unsigned long valuemask,
register XSetWindowAttributes *attributes);
extern int _XDefaultError(
Display *dpy,
XErrorEvent *event);
extern int _XDefaultIOError(
Display *dpy);
extern void _XSetClipRectangles (
register Display *dpy,
GC gc,
int clip_x_origin, int clip_y_origin,
XRectangle *rectangles,
int n,
int ordering);
_XFUNCPROTOEND
#endif /* _XLIBINT_H_ */
-------------- next part --------------
On Jun 28, 2004, at 2:33 PM, Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 02:31:45PM -0400, Michael Frey wrote:
>> There is Xlibint.h in X11/include/X11 and when I delete it I can no
>> longer build.
>
> Sorry, I meant everywhere but X11/include/X11. There's not one in
> /usr/include or /opt/fdo/include or anything?
>
>> [root@chawa freedesktop]# cd X11/
>> [root@chawa X11]# make
>> Making all in include
>> make[1]: Entering directory
>> `/home/michael.frey/freedesktop/X11/include'
>> make[1]: *** No rule to make target `X11/Xlibint.h', needed by
>> `all-am'. Stop.
>> make[1]: Leaving directory
>> `/home/michael.frey/freedesktop/X11/include'
>> make: *** [all-recursive] Error 1
>>
>> I even tried to delete everything and start over. I use the build
>> script that is posted on the freedesktop website.
>
> That's weird - it seems to work fine here. X11/include/X11/Xlibint.h
> should contain this define.
>
> --
> Daniel Stone
> <[email protected]>
> freedesktop.org: powering your desktop
> http://www.freedesktop.org
From daniel at freedesktop.org Mon Jun 28 11:44:05 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 11:44:06 2004
Subject: [Xorg] debrix related: corrupted screen with nv
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 08:32:34PM +0000, Giovanni wrote:
> Alle 18:32, luned? 28 giugno 2004, Daniel Stone ha scritto:
> > On Mon, Jun 28, 2004 at 08:23:26PM +0000, Giovanni wrote:
> > > the server starts with no problem, mouse and keyboard is ok, it's stable,
> > > but the screen looks corrupted and with fonts messed up...anyway I'm glad
> > > someone is finally working on nvidia :)
> >
> > You're not building with --enable-composite, are you? If yes, disable it
> > - it's broken. If no, try with 'Option "NoAccel"'.
> no, it wasn't with --enable-composite...i tried with that but i got this
> error:
> [...]
Yeah. Don't do that. :)
> anyway..it works with Option "NoAccel" :)
Word. I think I know what the problem is - quite possibly the
X_BYTE_ORDER define not carrying over ... although that should get set
in debrix.h. Ho hum.
I don't even have an nv card, so would someone (hi clee!) with an nv
card like to start poking and see what they can find?
:) d
--
Daniel Stone <[email protected]>
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/20040629/d5dbaa6d/attach
ment.pgp
From daniel at freedesktop.org Mon Jun 28 12:01:03 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 12:01:04 2004
Subject: [Xorg] Error building X11
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 02:57:56PM -0400, Michael Frey wrote:
> I see now look at the function name there is an l missing in the word
> display.
>
> GetDflt.c:240: error: `XlibDispayDfltRMDB' undeclared (first use in
> this function)
Thanks a lot - fixed in CVS.
--
Daniel Stone <[email protected]>
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/20040629/002b1d8a/attach
ment.pgp
From grifis87 at virgilio.it Mon Jun 28 13:32:34 2004
From: grifis87 at virgilio.it (Giovanni)
Date: Mon Jun 28 13:57:48 2004
Subject: [Xorg] debrix related: corrupted screen with nv
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Anyway, is debrix intended (once complete) to replace the monolitical Xorg and
be merged to trunk? It would be great :)
From loc at toya.net.pl Mon Jun 28 14:09:58 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Mon Jun 28 14:10:01 2004
Subject: [Xorg] debrix related: corrupted screen with nv
In-Reply-To: <[email protected]>
References: <[email protected]> <20040628183224.GQ21053@
fooishbar.org> <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 08:32:34PM +0000, Giovanni wrote:
>>
>>no, it wasn't with --enable-composite...i tried with that but i got this
>>error:
>>[...]
>
> Yeah. Don't do that. :)
You know there is an easy fix for that error? But if building
--enable-composite is depreciated maybe comment it out in configure.ac?
PS. I'll kill myself one day if I don't start using Reply All :D
--
Regards,
Jakub Piotr C?apa
From asterius at airpost.net Mon Jun 28 15:28:30 2004
From: asterius at airpost.net (Asterius Pandoras)
Date: Mon Jun 28 15:28:32 2004
Subject: [Xorg] Xfree lib and headers deps
Message-ID: <[email protected]>
Copiled xserver and it looks great. The probelm is that I don't have
libs and headers required for compiling other X apps which depend on it.
How would one go to compile them (probably from the same CVS, not sure).
I only need bare minimum without the installing that XFRee86 huge thing.
Any pointers are appreciated.
Asterius.
From loc at toya.net.pl Mon Jun 28 18:27:55 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Mon Jun 28 18:28:03 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 05:42:15PM +0200, Jakub Piotr C?apa wrote:
>
>>Daniel Stone wrote:
>>
>>>Nope. I guess the code has always just relied on it being a module. Try
>>>removing the two scanpci libraries from the Xorg linking in
>>>hw/xorg/Makefile.am, and changing hw/xorg/scanpci/Makefile.am:
>>>noinst_LIBRARIES = libscanpci.a libpcidata.a
>>>libscanpci_a_SOURCES = foo
>>>libpcidata_a_SOURCES = bar
>>>--
>>>to:
>>>lib_LTLIBRARIES = libscanpci.la libpcidata.la
>>>libscanpci_la_SOURCES = foo
>>>libpcidata_la_SOURCES = bar
>>
>>Tried. Works either way. When compiled in I just disable the probing
>>stuff from xf86pciBus.c lines 1712-1730 + remove it from the baseModules
>>and it works.
>
> Hm, cool.
I've patched [1] the ati driver not to load builtin modules but I'm
afraid it's a hack more than a fix...
Is it possible for someone to load a module which doesn't know about our
builtins? For example a binary driver or sth like that?
Maybe I'm panicking and we can be sure that everybody writing anything
having any chances to work as a debrix module will know what we have
statically linked (and we will not change our minds in this matter).
If not we need a way to allow inserting modules iff (if and only if)
they are not built into the core. Sadly I fail to see a way to do it. If
LoadModule is to succed it should return a cool brand new ModuleDescPtr.
Can we make a valid one for builtin modules?
>>>Hrm. I have on idea without an extended look, and I have to start this
>>>stupid pastry again.
>>
>>It would help if I knew how to get vgahw symbols exported. (and why
>>these are).
>
> If function foosym needs to be exported, you need to add:
> SYMFUNC(foosym);
> to hw/xorg/loader/xf86sym.c; if it's a variable:
> SYMVAR(foosym);
It's almost like that. After playing with this it seems you need to
explicitly SYMFUNC only one symbol from each object file to export them
all. Or sth. similar - I added vgaHWInit and got them all. ;)
I have tried to add all needed exports but stopped in the middle and
went to sleep. My current patch is available [2]. (also adds some files
to int10 because it had missing symbols whan linking the main binary)
[1]
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-modules.patch?rev=1.1
[2]
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-driver-ati-modules.patch?
rev=1.2
I'm starting to doubt if statically linking everything was a good
idea... Maybe it would be easier to expose needed variables with
functions? Are there any other reasons you merged everything into one
binary?
--
Regards,
Jakub Piotr C?apa
From mfrey at pepper.com Mon Jun 28 18:33:34 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 18:33:37 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <1087425732.973.5.camel@leguin>
References: <[email protected]>
<1087425732.973.5.camel@leguin>
Message-ID: <[email protected]>
After reading the code in kaa.c I noticed that a video driver who
supplies acceleration code is only called if there is available
offscreen pixmaps other wise it falls through and uses fbdev.
for example: in kaaFillRegionSolid
if (pScreenPriv->enabled &&
(pPixmap = kaaGetOffscreenPixmap (pDrawable, &xoff, &yoff)) &&
(*pKaaScr->info->PrepareSolid) (pPixmap, GXcopy, FB_ALLONES, pixel))
I have a video card that only has enough memory for the on screen frame
buffer but It has a 2DBLT engine. I have code that I used in the
XFree86 tree with kdrive that works great and I want to move to the new
kdrive from freedesktop. Can someone tell me if it is possible to use
acceleration routines without using offscreen pixamps?
Thanks in advance,
Michael
From keithp at keithp.com Mon Jun 28 18:43:31 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 28 18:43:50 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: Your message of "Mon, 28 Jun 2004 21:33:34 EDT."
<[email protected]>
Message-ID: <[email protected]>
Around 21 o'clock on Jun 28, Michael Frey wrote:
> I have a video card that only has enough memory for the on screen frame
> buffer but It has a 2DBLT engine. I have code that I used in the
> XFree86 tree with kdrive that works great and I want to move to the new
> kdrive from freedesktop. Can someone tell me if it is possible to use
> acceleration routines without using offscreen pixamps?
The frame buffer is a pixmap, so any windows drawn to the visible frame
buffer will be acceleratable.
With Composite, not all windows are drawn to the visible frame buffer,
hence the strange conditions in the kaa code.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040628/840d5226/attach
ment.pgp
From mfrey at pepper.com Mon Jun 28 18:45:49 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 18:45:52 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
So --- should I be building without Composite?
Michael
On Jun 28, 2004, at 9:43 PM, Keith Packard wrote:
>
> Around 21 o'clock on Jun 28, Michael Frey wrote:
>
>> I have a video card that only has enough memory for the on screen
>> frame
>> buffer but It has a 2DBLT engine. I have code that I used in the
>> XFree86 tree with kdrive that works great and I want to move to the
>> new
>> kdrive from freedesktop. Can someone tell me if it is possible to use
>> acceleration routines without using offscreen pixamps?
>
> The frame buffer is a pixmap, so any windows drawn to the visible frame
> buffer will be acceleratable.
>
> With Composite, not all windows are drawn to the visible frame buffer,
> hence the strange conditions in the kaa code.
>
> -keith
>
>
From keithp at keithp.com Mon Jun 28 18:49:50 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 28 18:50:05 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: Your message of "Mon, 28 Jun 2004 21:45:49 EDT."
<[email protected]>
Message-ID: <[email protected]>
Around 21 o'clock on Jun 28, Michael Frey wrote:
> So --- should I be building without Composite?
Not at all -- it's an extension which has no effect until some application
requests its functionality (like a compositing manager). When you do run
xcompmgr, you'll essentially end up with a shadow frame buffer, but even
that is quite acceptably fast.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040628/2850cf21/attach
ment.pgp
From mfrey at pepper.com Mon Jun 28 18:56:08 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 18:56:11 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
ok,
Excuse my ignorance, but I am still a bit confused. The line of code I
referred to earlier
(pPixmap = kaaGetOffscreenPixmap (pDrawable, &xoff, &yoff)) &&
in kaa.c seems to always return NULL and therefore will never call the
PrepareSolid as well as the Solid functions defined by my driver. Or
is this a bug in the init of my driver not filling out the structures
properly?
Michael
On Jun 28, 2004, at 9:49 PM, Keith Packard wrote:
>
> Around 21 o'clock on Jun 28, Michael Frey wrote:
>
>> So --- should I be building without Composite?
>
> Not at all -- it's an extension which has no effect until some
> application
> requests its functionality (like a compositing manager). When you do
> run
> xcompmgr, you'll essentially end up with a shadow frame buffer, but
> even
> that is quite acceptably fast.
>
> -keith
>
>
From keithp at keithp.com Mon Jun 28 18:59:08 2004
From: keithp at keithp.com (Keith Packard)
Date: Mon Jun 28 18:59:23 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: Your message of "Mon, 28 Jun 2004 21:56:08 EDT."
<[email protected]>
Message-ID: <[email protected]>
Around 21 o'clock on Jun 28, Michael Frey wrote:
> Excuse my ignorance, but I am still a bit confused. The line of code I
> referred to earlier
> (pPixmap = kaaGetOffscreenPixmap (pDrawable, &xoff, &yoff)) &&
> in kaa.c seems to always return NULL and therefore will never call the
> PrepareSolid as well as the Solid functions defined by my driver.
Well, there was a bug in the fbdev driver that set the memory_size value
to zero. I fixed that yesterday though; perhaps you aren't up to date?
(or perhaps it's still broken in some way?)
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040628/b1c1c31a/attach
ment.pgp
From mfrey at pepper.com Mon Jun 28 19:00:36 2004
From: mfrey at pepper.com (Michael Frey)
Date: Mon Jun 28 19:00:39 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
I will update from CVS and check it out.
Thanks for the help.
Michael
On Jun 28, 2004, at 9:59 PM, Keith Packard wrote:
>
> Around 21 o'clock on Jun 28, Michael Frey wrote:
>
>> Excuse my ignorance, but I am still a bit confused. The line of code
>> I
>> referred to earlier
>> (pPixmap = kaaGetOffscreenPixmap (pDrawable, &xoff, &yoff)) &&
>> in kaa.c seems to always return NULL and therefore will never call the
>> PrepareSolid as well as the Solid functions defined by my driver.
>
> Well, there was a bug in the fbdev driver that set the memory_size
> value
> to zero. I fixed that yesterday though; perhaps you aren't up to date?
> (or perhaps it's still broken in some way?)
>
> -keith
>
>
From daniel at freedesktop.org Mon Jun 28 23:48:19 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 23:48:22 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tue, Jun 29, 2004 at 03:27:55AM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >Hm, cool.
>
> I've patched [1] the ati driver not to load builtin modules but I'm
> afraid it's a hack more than a fix...
THe long-term mix is to have the loader just return for built-ins.
> Is it possible for someone to load a module which doesn't know about our
> builtins? For example a binary driver or sth like that?
It might be able to load binary modules with the XFree86-ELF loader
(elfloader.c). Balance of probabilities, no: it didn't even load the
fbdev module for a while. Because we're doing so much stuff, it's really
a matter of make sweeping change, see just how much stuff you broke,
unbreak for the specific cases you encounter, realise the damage is
greater than you thought, unbreak for the specific cases, move on to the
next TODO item, rinse, repeat.
> Maybe I'm panicking and we can be sure that everybody writing anything
> having any chances to work as a debrix module will know what we have
> statically linked (and we will not change our minds in this matter).
> If not we need a way to allow inserting modules iff (if and only if)
> they are not built into the core. Sadly I fail to see a way to do it. If
> LoadModule is to succed it should return a cool brand new ModuleDescPtr.
> Can we make a valid one for builtin modules?
Sure we can.
> >If function foosym needs to be exported, you need to add:
> >SYMFUNC(foosym);
> >to hw/xorg/loader/xf86sym.c; if it's a variable:
> >SYMVAR(foosym);
>
> It's almost like that. After playing with this it seems you need to
> explicitly SYMFUNC only one symbol from each object file to export them
> all. Or sth. similar - I added vgaHWInit and got them all. ;)
> I have tried to add all needed exports but stopped in the middle and
> went to sleep. My current patch is available [2]. (also adds some files
> to int10 because it had missing symbols whan linking the main binary)
Hm, interesting ... or not.
That makes sense, because vgaHWInit will make the module pointer, which
will reference almost every other vgahw symbol.
> [1]
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-modules.patch?rev=1.1
> [2]
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-driver-ati-modules.patc
h?rev=1.2
I'll look at these later: I'm still trying to deal with the fact that I
just woke up, it's 4:48pm, and I have a billion things to do today.
> I'm starting to doubt if statically linking everything was a good
> idea... Maybe it would be easier to expose needed variables with
> functions? Are there any other reasons you merged everything into one
> binary?
Cleanliness is next to godliness. Also, the variable interdependency
thing: the nv driver doesn't really work otherwise. Ditto fbdev.
--
Daniel Stone <[email protected]>
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/20040629/95a07e2e/attach
ment.pgp
From daniel at freedesktop.org Mon Jun 28 23:48:36 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Mon Jun 28 23:48:39 2004
Subject: [Xorg] debrix related: corrupted screen with nv
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Mon, Jun 28, 2004 at 08:32:34PM +0000, Giovanni wrote:
> Anyway, is debrix intended (once complete) to replace the monolitical Xorg and

> be merged to trunk? It would be great :)
I hope so, yah.
--
Daniel Stone <[email protected]>
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/20040629/360e1724/attach
ment.pgp
From loc at toya.net.pl Tue Jun 29 02:17:07 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Tue Jun 29 02:17:21 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Tue, Jun 29, 2004 at 03:27:55AM +0200, Jakub Piotr C?apa wrote:
>
>>Daniel Stone wrote:
>>
>>>Hm, cool.
>>
>>I've patched [1] the ati driver not to load builtin modules but I'm
>>afraid it's a hack more than a fix...
>
> THe long-term mix is to have the loader just return for built-ins.
Cool. :)
>>Is it possible for someone to load a module which doesn't know about our
>>builtins? For example a binary driver or sth like that?
>
> It might be able to load binary modules with the XFree86-ELF loader
> (elfloader.c). Balance of probabilities, no: it didn't even load the
> fbdev module for a while. Because we're doing so much stuff, it's really
> a matter of make sweeping change, see just how much stuff you broke,
> unbreak for the specific cases you encounter, realise the damage is
> greater than you thought, unbreak for the specific cases, move on to the
> next TODO item, rinse, repeat.
If we can return valid ModuleDescPtr for builtins that not a problem.
>>Maybe I'm panicking and we can be sure that everybody writing anything
>>having any chances to work as a debrix module will know what we have
>>statically linked (and we will not change our minds in this matter).
>>If not we need a way to allow inserting modules iff (if and only if)
>>they are not built into the core. Sadly I fail to see a way to do it. If
>>LoadModule is to succed it should return a cool brand new ModuleDescPtr.
>>Can we make a valid one for builtin modules?
>
> Sure we can.
If we can then no problem. Pitty I know too litle (yet) to make it work.
You don't know of any papers covering the module loader stuff, do you?
Only RTFSourceCode?
>>>If function foosym needs to be exported, you need to add:
>>>SYMFUNC(foosym);
>>>to hw/xorg/loader/xf86sym.c; if it's a variable:
>>>SYMVAR(foosym);
>>
>>It's almost like that. After playing with this it seems you need to
>>explicitly SYMFUNC only one symbol from each object file to export them
>>all. Or sth. similar - I added vgaHWInit and got them all. ;)
>>I have tried to add all needed exports but stopped in the middle and
>>went to sleep. My current patch is available [2]. (also adds some files
>>to int10 because it had missing symbols whan linking the main binary)
>
> Hm, interesting ... or not.
>
> That makes sense, because vgaHWInit will make the module pointer, which
> will reference almost every other vgahw symbol.
But it seems it doesn't really care which symbol I export. Event the
most stupid ones (like xf86int10Addr in int10/generic.c) will force
everything to go.
>>[1]
>>http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-modules.patch?rev=1.1
>>[2]
>>http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-driver-ati-modules.patc
h?rev=1.2
>
> I'll look at these later: I'm still trying to deal with the fact that I
> just woke up, it's 4:48pm, and I have a billion things to do today.
Ok. :)
>>I'm starting to doubt if statically linking everything was a good
>>idea... Maybe it would be easier to expose needed variables with
>>functions? Are there any other reasons you merged everything into one
>>binary?
>
> Cleanliness is next to godliness. Also, the variable interdependency
> thing: the nv driver doesn't really work otherwise. Ditto fbdev.
I'm just not sure which is more clean - small binary + many modules or
one big binary.
--
Regards,
Jakub Piotr C?apa
From krh at bitplanet.net Tue Jun 29 02:42:14 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Tue Jun 29 02:43:40 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Keith Packard wrote:
> Around 19 o'clock on Jun 23, =?ISO-8859-1?Q?Kristian_H=F8gsberg?= wrote:
>
>
>>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.
>
>
>>One thing I'ld like to discuss is where to add the add and remove device
>>interface
>
>
> I'd like to think this belongs in the XInput extension.
I think when you add a new device you need to be able to specify the
same options as you can in xorg.conf. That's why my first suggestion
was to add it to XFree86-Misc (or possible Xorg-Misc), as it would be
specific to the xorg server. But I'm thinking that maybe the request I
suggested is generic enough that it could be in XInput: basically you
give the name of the new device, the name of the driver for the new
device and a list of string (key, value) options.
> There are other
> changes which we can add to that extension at the same time and rev the
> protocol version. Coding up backward-compatibility stuff will also be
> necessary; take a look at how XFixes manages that (client sends its
> version number, X server ensures protocol is compatible with that version).
OK, I'll look into that.
Kristian
From krh at bitplanet.net Tue Jun 29 03:08:26 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Tue Jun 29 03:09:52 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]
m>
<[email protected]>
Message-ID: <[email protected]>
Egbert Eich wrote:
> Keith Packard writes:
> >
> > Around 19 o'clock on Jun 23, =?ISO-8859-1?Q?Kristian_H=F8gsberg?= wrote:
> >
> > > 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.
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.
> > > One thing I'ld like to discuss is where to add the add and remove device
> > > interface
> >
> > I'd like to think this belongs in the XInput extension. There are other
> > changes which we can add to that extension at the same time and rev the
> > protocol version. Coding up backward-compatibility stuff will also be
> > necessary; take a look at how XFixes manages that (client sends its
> > version number, X server ensures protocol is compatible with that version).
> >
>
> 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.
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.
Kristian
From krh at bitplanet.net Tue Jun 29 03:20:27 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Tue Jun 29 03:21:53 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
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".
> 3)I think there is some functionality missing like accelated moving
> or tapping.
> 4)allowing more than one core device (mouse/keyboard) to be independed
> from each other, It doesn't make much sense when using on one display
> but if you want for example one keyboard per display for 2 people
> working..
Sure, this is cool stuff, but I'm not sure how much work it would be, or
if it would be worthwhile.
> 5)Personaly I think that xinput should handle keyboard as well,
> (the basic hardware level not the xkb one), I don't know if it's related
> to xinput but probebly some changes in they keysym handling might be
> nice.
In what way? You can change the core keyboard with XInput, what else
should it do?
[...]
Kristian
From elylevy-xserver at cs.huji.ac.il Tue Jun 29 03:28:31 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Tue Jun 29 03:28:35 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tue, 29 Jun 2004, [UTF-8] Kristian H=C3=B8gsberg 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:)
> > 3)I think there is some functionality missing like accelated moving
> > or tapping.
> > 4)allowing more than one core device (mouse/keyboard) to be independed
> > from each other, It doesn't make much sense when using on one display
> > but if you want for example one keyboard per display for 2 people
> > working..
>
> Sure, this is cool stuff, but I'm not sure how much work it would be, or
> if it would be worthwhile.
>
> > 5)Personaly I think that xinput should handle keyboard as well,
> > (the basic hardware level not the xkb one), I don't know if it's rela=
ted
> > to xinput but probebly some changes in they keysym handling might be
> > nice.
>
> In what way? You can change the core keyboard with XInput, what else
> should it do?
What xserver does with the keyboard now, you need it to add more
flexibility to what keyboard does what, (like above going to diffrent
display), or to change the keysym to unicode (if it's not in xkb?)
> [...]
>
> Kristian
>
From krh at bitplanet.net Tue Jun 29 04:36:53 2004
From: krh at bitplanet.net (=?UTF-8?B?S3Jpc3RpYW4gSMO4Z3NiZXJn?=)
Date: Tue Jun 29 04:38:20 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Egbert Eich wrote:
> Kristian H?gsberg writes:
> > Hi all,
> >
> > I've been working on making the X.org server hotplug aware with respect
> > to input devices. The current situation is that all devices must be
> > setup in the config file and adding new devices requires config file
> > editing and server restart. What I've been trying to implement is that
> > you can plug in an input device while the X server is running and it
> > will show up as a new XInput device.
> >
> > The overall design I'm thinking of is to keep the device discovery
> > mechanism out of the X server. By adding requests to add and remove
> > devices a client program can monitor hotplug events and tell the server
> > to add or remove devices accordingly.
>
> Having the discover mechanism live outside of the X server is only useful if
> it is generic to the system and not specific to X. Any program interested
> in input devices should be able to take advantage of its services.
>
> 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.
[...]
> > One thing I'ld like to discuss is where to add the add and remove device
> > interface -- I dont think XFree86-Misc is the right place. My first
> > approach to this was that the new functionality should be an Xorg
> > private interface, but I'm thinking that maybe it would be better if it
> > was a standardized extension to XInput. In that case, is the proposed
> > interface too Xorg specific?
>
> 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.
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...
> The XInput extension may have to be extended to be able to send events
> to notify clients about the new device. Also it may be useful to provide
> more information about the device to the clients (for example some ID
> or serial number) so the client is able to (re)identify devices.
>
> >
> > Comments are welcome. I'm currently trying to get my prototype cleaned
> > up, and then I'll attach it to a bugzilla entry
> >
>
> I hope my comments have been helpful. This is certainly an importand issue
> which should be discussed.
Definitely, thanks.
Kristian
From anderson at netsweng.com Tue Jun 29 02:20:19 2004
From: anderson at netsweng.com (Stuart Anderson)
Date: Tue Jun 29 04:49:14 2004
Subject: [Xorg] VSW4 test suite
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <Pine.LNX.4.56.0406290518560.1976@localhost>
On Mon, 28 Jun 2004, Egbert Eich wrote:
> If someone could give me a pointer to the (original) sources I
> would take care of adding it to CVS and put up some documentation.
We have prebuilt versions of the test suite currently located at
http://ftp.freestandards.org/pub/lsb/test_suites/beta/binary/runtime/
This is currently configured to test the liobraries against Xvfb, but it
would only take 1 or 2 steps to change it to run against whatever server
you wanted to test.
Stuart
Stuart R. Anderson [email protected]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
From daniel at freedesktop.org Tue Jun 29 07:14:53 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Tue Jun 29 07:14:56 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tue, Jun 29, 2004 at 11:17:07AM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >Sure we can.
>
> If we can then no problem. Pitty I know too litle (yet) to make it work.
> You don't know of any papers covering the module loader stuff, do you?
> Only RTFSourceCode?
As XFree86Loader is defined, the ModuleRec exists. It's pretty much
UTSL, except there are a couple of documents floating around on the
XFree86 4.x design somewhere that IIRC cover the loader.
> >Hm, interesting ... or not.
> >
> >That makes sense, because vgaHWInit will make the module pointer, which
> >will reference almost every other vgahw symbol.
>
> But it seems it doesn't really care which symbol I export. Event the
> most stupid ones (like xf86int10Addr in int10/generic.c) will force
> everything to go.
Odd, but cool.
> >Cleanliness is next to godliness. Also, the variable interdependency
> >thing: the nv driver doesn't really work otherwise. Ditto fbdev.
>
> I'm just not sure which is more clean - small binary + many modules or
> one big binary.
To me, the idea of having it install as few things as possible is
immensely attractive.
--
Daniel Stone <[email protected]>
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/20040630/6d7fffdc/attach
ment.pgp
From mfrey at pepper.com Tue Jun 29 07:15:07 2004
From: mfrey at pepper.com (Michael Frey)
Date: Tue Jun 29 07:15:11 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
A little bit further.... Now I am having trouble in kaaPixmapUseScreen.
KaaPixmapPriv (pPixmap);
This is always returning NULL. I also noticed that the macro
KaaSetPixmapPriv(p,a)
is never being called. How does the devPrivates get set for the pixmap?
Michael
On Jun 28, 2004, at 9:59 PM, Keith Packard wrote:
>
> Around 21 o'clock on Jun 28, Michael Frey wrote:
>
>> Excuse my ignorance, but I am still a bit confused. The line of code
>> I
>> referred to earlier
>> (pPixmap = kaaGetOffscreenPixmap (pDrawable, &xoff, &yoff)) &&
>> in kaa.c seems to always return NULL and therefore will never call the
>> PrepareSolid as well as the Solid functions defined by my driver.
>
> Well, there was a bug in the fbdev driver that set the memory_size
> value
> to zero. I fixed that yesterday though; perhaps you aren't up to date?
> (or perhaps it's still broken in some way?)
>
> -keith
>
>
From roland.mainz at nrubsig.org Tue Jun 29 07:48:57 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Tue Jun 29 07:49:24 2004
Subject: [Xorg] MacOSX problems...
Message-ID: <[email protected]>
Hi!
----
I am currently trying to get the Xorg tree on MacOSX working again - it
seems to be broken since several weeks.
Two questions:
- Is anyone here working on MacOSX, too ?
- Does MacOSX have strtok_r() somewhere ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From yernst at ndsisrael.com Tue Jun 29 07:58:43 2004
From: yernst at ndsisrael.com (Ernst, Yehuda)
Date: Tue Jun 29 07:59:25 2004
Subject: [Xorg] tvout fedora2
Message-ID: <[email protected]>
Hello!
Can some one give an example of how xorg.conf should look like if i have intel v
ideo board i810
and i want to enable tv out?
Yehuda Ernst
NDS Technologies Israel Ltd. mailto:[email protected]>
Jerusalem Tel: +972 (2) 589-4427
PO Box 23012 Fax: +972 (2) 589-4825
Israel. 91235 Cell +972 55 664427
********************************************************************************
***
Information contained in this email message is intended only for use of the indi
vidual or entity named above. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended re
cipient, you are hereby notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this communi
cation in error, please immediately notify the [email protected] and destroy th
e original message.
********************************************************************************
***
From roland.mainz at nrubsig.org Tue Jun 29 08:11:58 2004
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Tue Jun 29 08:12:19 2004
Subject: [Xorg] CVS warnings at commit...
Message-ID: <[email protected]>
Hi!
----
Does anyone know what is going wrong below:
-- snip --
cvs commit: warning: commitinfo line contains no format strings:
"/cvs/xorg/CVSROOT/commitcheck"
Appending defaults (" %r/%p %s"), but please be aware that this usage is
deprecated.
cvs commit: warning: commitinfo line contains no format strings:
"/cvs/xorg/CVSROOT/commitcheck"
Appending defaults (" %r/%p %s"), but please be aware that this usage is
deprecated.
/cvs/xorg/xc/ChangeLog,v <-- ChangeLog
new revision: 1.76; previous revision: 1.75
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.
/cvs/xorg/xc/extras/Mesa/src/mesa/main/imports.h,v <-- imports.h
new revision: 1.2; previous revision: 1.1
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.
Mailing the commit message to [email protected]...
-- snip --
... it seems the commit is working properly, but somehow I don't like
the warnings above. Is there a way to get rid of them ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
From daniel at freedesktop.org Tue Jun 29 08:16:08 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Tue Jun 29 08:16:09 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Tue, Jun 29, 2004 at 05:11:58PM +0200, Roland Mainz wrote:
>
> Hi!
>
> ----
>
> Does anyone know what is going wrong below:
> -- snip --
> cvs commit: warning: commitinfo line contains no format strings:
> "/cvs/xorg/CVSROOT/commitcheck"
> Appending defaults (" %r/%p %s"), but please be aware that this usage is
> deprecated.
> cvs commit: warning: commitinfo line contains no format strings:
> "/cvs/xorg/CVSROOT/commitcheck"
> Appending defaults (" %r/%p %s"), but please be aware that this usage is
> deprecated.
> /cvs/xorg/xc/ChangeLog,v <-- ChangeLog
> new revision: 1.76; previous revision: 1.75
> 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.
> /cvs/xorg/xc/extras/Mesa/src/mesa/main/imports.h,v <-- imports.h
> new revision: 1.2; previous revision: 1.1
> 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.
> Mailing the commit message to [email protected]...
> -- snip --
>
> ... it seems the commit is working properly, but somehow I don't like
> the warnings above. Is there a way to get rid of them ?
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.
--
Daniel Stone <[email protected]>
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/20040630/b81962c4/attach
ment.pgp
From loc at toya.net.pl Tue Jun 29 08:16:25 2004
From: loc at toya.net.pl (=?ISO-8859-2?Q?Jakub_Piotr_C=B3apa?=)
Date: Tue Jun 29 08:16:39 2004
Subject: [Xorg] debrix
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Tue, Jun 29, 2004 at 11:17:07AM +0200, Jakub Piotr C?apa wrote:
>
>>Daniel Stone wrote:
>>>Hm, interesting ... or not.
>>>
>>>That makes sense, because vgaHWInit will make the module pointer, which
>>>will reference almost every other vgahw symbol.
>>
>>But it seems it doesn't really care which symbol I export. Event the
>>most stupid ones (like xf86int10Addr in int10/generic.c) will force
>>everything to go.
>
> Odd, but cool.
Yup.
>>>Cleanliness is next to godliness. Also, the variable interdependency
>>>thing: the nv driver doesn't really work otherwise. Ditto fbdev.
>>
>>I'm just not sure which is more clean - small binary + many modules or
>>one big binary.
>
> To me, the idea of having it install as few things as possible is
> immensely attractive.
Maybe you are right. :) I'll try to play with making the loader return
good values for builtins.
I've finaly made it. Now it compiles without errors and even works.
Patches for debrix:
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-many_fixes.patch?rev=1.3
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-modules.patch?rev=1.2
The first is needed for me (the linux/config.h and
Xdmcp.h -> X11/Xdmcp.h includes).
The second one exports some more modules and also replaces some
-I$(srcdir)/../(...) with one -I$(srcdir)/../ in the Makefile and
#include "(...)/header_file.h" in sources. In my opinion it's more
clear. I could finish it for all the files in hw/xorg if it would be useful.
Hacks for debrix-driver-ati (only the radeon part, not the r128):
http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-driver-ati-modules.patch?
rev=1.2
--
Regards,
Jakub Piotr C?apa
From mfrey at pepper.com Tue Jun 29 08:18:18 2004
From: mfrey at pepper.com (Michael Frey)
Date: Tue Jun 29 08:18:23 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Never mind -- I was not setting the OFFSCREENPIXMAP flag upon init.
Sorry for the chatter.
Michael
On Jun 29, 2004, at 10:15 AM, Michael Frey wrote:
>
> A little bit further.... Now I am having trouble in kaaPixmapUseScreen.
>
> KaaPixmapPriv (pPixmap);
> This is always returning NULL. I also noticed that the macro
> KaaSetPixmapPriv(p,a)
> is never being called. How does the devPrivates get set for the
> pixmap?
>
> Michael
>
>
> On Jun 28, 2004, at 9:59 PM, Keith Packard wrote:
>
>>
>> Around 21 o'clock on Jun 28, Michael Frey wrote:
>>
>>> Excuse my ignorance, but I am still a bit confused. The line of
>>> code I
>>> referred to earlier
>>> (pPixmap = kaaGetOffscreenPixmap (pDrawable, &xoff, &yoff)) &&
>>> in kaa.c seems to always return NULL and therefore will never call
>>> the
>>> PrepareSolid as well as the Solid functions defined by my driver.
>>
>> Well, there was a bug in the fbdev driver that set the memory_size
>> value
>> to zero. I fixed that yesterday though; perhaps you aren't up to
>> date?
>> (or perhaps it's still broken in some way?)
>>
>> -keith
>>
>>
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
From yernst at ndsisrael.com Tue Jun 29 08:39:05 2004
From: yernst at ndsisrael.com (Ernst, Yehuda)
Date: Tue Jun 29 08:39:42 2004
Subject: [Xorg] how do i config xorg with gui?
Message-ID: <[email protected]>
Yehuda Ernst
NDS Technologies Israel Ltd. mailto:[email protected]>
Jerusalem Tel: +972 (2) 589-4427
PO Box 23012 Fax: +972 (2) 589-4825
Israel. 91235 Cell +972 55 664427
********************************************************************************
***
Information contained in this email message is intended only for use of the indi
vidual or entity named above. If the reader of this message is not the intended
recipient, or the employee or agent responsible to deliver it to the intended re
cipient, you are hereby notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have received this communi
cation in error, please immediately notify the [email protected] and destroy th
e original message.
********************************************************************************
***
From alan at lxorguk.ukuu.org.uk Tue Jun 29 08:15:52 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Tue Jun 29 09:18:48 2004
Subject: [Xorg] The big multiconsole nasty
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
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
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..
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 ?
From Alan.Coopersmith at Sun.COM Tue Jun 29 10:54:28 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Tue Jun 29 10:54:32 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
Message-ID: <[email protected]>
-------- Original Message --------
Subject: Project Looking Glass Open Source Announcement
Date: Tue, 29 Jun 2004 10:46:06 -0700
From: Lauren Zuravleff <[email protected]>
Reply-To: [email protected]
To: [email protected]
Project Looking Glass Open Source
---------------------------------
Sun Microsystems is contributing Project Looking Glass, based on
Java(tm) technology, to the open source community. Project Looking Glass
is an exploration project to bring innovative 3D features to the desktop
environment. The desktop interface will offer an intuitive, new 3D
environment to interact with desktop applications featuring window
transparency, rotation, zoom, multiple desktop workspaces and
miniaturization.Project Looking Glass offers a platform to realize far
richer and more entertaining user experience for existing and new
applications in 2D or 3D. The technology enables developers to build
highly visual 3D desktops and applications that will run on Linux
systems such as Sun's Java Desktop System. The Solaris(tm) environment
will be supported in near future.
What does this mean to you?
---------------------------
If you're a software developer, please go to
http://lg3d-core.dev.java.net and download this early version of the
code and join the community in developing the 3D desktop.
Interested in using the Project Looking Glass? The project is in very
early stages and a commercial version is not available yet. Please go to
http://www.sun.com/software/project-looking-glass to keep up to date on
our progress.
Why Open Source?
----------------
Project Looking Glass is in its infancy, and we'd like to explore lots
of ideas and possibilities. We're releasing the Project Looking Glass
code to the whole community to explore every aspect of the technology
rather than restricting access to a privileged few. We believe this open
development is an excellent model to pursue this exciting and vast
opportunity. So, your involvement is eagerly anticipated. We believe
new dimension of developer innovation by making Sun's cutting edge
technology available at Sun's 3D Desktop Technology Open Source Project
on java.net.
We have been working for several months on cleaning the software up,
providing basic features and functionality key to 3D window management.
A key focus was looking at the existing 2D desktop applications,
ensuring minimal compatibility and performance problems. The next step
is to look what else we can do to foster real world 3D interactivity. We
decided to open source this at a very early stage to ensure that we got
good feedback from the community.
What's in the Open Source Project?
----------------------------------
The following features are now available in the Project Looking Glass
open source release:
3D Window Manager Platform - Java 3D based highly scalable 3D platform
with client-server model support.
3D Window Manager and Application Development API - Java API to develop
new 3D desktop applications and 3D desktop Window Manager features.
Native Application Integration Module - Allows developers to run
conventional X11 applications in the 3D environment.
Sample 3D Window Manager - provides a simple sample implementation for
testing and demonstration purposes
3D Environment Lite - Enables developers to run a simplified 3D
environment as an application on a Java 3D enabled platform including
Linux and Solaris environments. This serves as a development tool to
test implementations.
This is all available at: http://lg3d-core.dev.java.net
What's the licensing model?
---------------------------
There are three license choices for developers interested in creating
applications using Project Looking Glass.
For developers who are interested in reviewing, revising, and
redistributing the source code as part of their own application, Project
Looking Glass has been submitted as an Open Source project on java.net
under the GNU Public License, or GPL.
For developers who are interested in developing an application on top of
the existing Project Looking Glass platform without reviewing and/or
altering the code base, there is a binary version of the current state
of the project available for download under a traditional Binary Code
License. This is also available on java.net.
Finally, for developers or organizations interested in other uses or
revising the source code but wish to keep their implementation and
related application proprietary, please contact Sun at
[email protected].
Project Looking Glass Community Meeting
---------------------------------------
Wednesday June 30, 2004
4:30pm to 6:00pm
The Argent Hotel, City Room
San Francisco, California, USA
http://www.argenthotel.com/location.htm
4:00-4:30 Registration
4:30-4:45 Welcome, Introductions, and 3D Desktop Project Demo
4:45-5:30 Technology Overview, Possible Sub Projects, How to Get Started
5:30-6:00 Q&A and Networking
Please join the conversation with the Project Looking Glass developers
from Sun Microsystems. This meeting will be technically focused
introducing developers to the project and letting them know how to get
involved.
You can meet the team from "Project Looking Glass" and other developers
while enjoying food and refreshments. There is open admission. You do
not need a JavaOne Conference Pass to attend.
There will be no webcast available, but we will post the information
available at the meeting on the website. We'll also have several
presentations and Project Looking Glass at JavaOne, and we'll post as
many as we can on the web.
You can see Hideya Kawahara on stage with Jonathan Schwartz and Scott
McNealy of Sun Microsystems demonstrating the Project Looking Glass
technology and announcing the open source project at
http://java.sun.com/javaone/ (select View Webcast).
If you have any questions, please send them to:
[email protected]
Sun's Project Looking Glass Team
From torgeir at pobox.com Tue Jun 29 11:04:06 2004
From: torgeir at pobox.com (Torgeir Veimo)
Date: Tue Jun 29 11:04:14 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Tue, 2004-06-29 at 10:54 -0700, Alan Coopersmith wrote:
> Project
> Looking Glass has been submitted as an Open Source project on java.net
> under the GNU Public License, or GPL.
So it will never be part of any release by xorg then...
--
Torgeir Veimo <[email protected]>
From alexdeucher at gmail.com Tue Jun 29 11:08:03 2004
From: alexdeucher at gmail.com (Alex Deucher)
Date: Tue Jun 29 11:08:06 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tue, 29 Jun 2004 19:04:06 +0100, Torgeir Veimo <[email protected]> wrote:
>
> On Tue, 2004-06-29 at 10:54 -0700, Alan Coopersmith wrote:
> > Project
> > Looking Glass has been submitted as an Open Source project on java.net
> > under the GNU Public License, or GPL.
>
> So it will never be part of any release by xorg then...
Why would it need to be? GNOME and KDE are not part of xorg.
Alex
>
> --
> Torgeir Veimo <[email protected]>
>
From daniel at freedesktop.org Tue Jun 29 11:12:05 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Tue Jun 29 11:12:10 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Tue, Jun 29, 2004 at 02:08:03PM -0400, Alex Deucher wrote:
> On Tue, 29 Jun 2004 19:04:06 +0100, Torgeir Veimo <[email protected]> wrote:
> > On Tue, 2004-06-29 at 10:54 -0700, Alan Coopersmith wrote:
> > > Project
> > > Looking Glass has been submitted as an Open Source project on java.net
> > > under the GNU Public License, or GPL.
> >
> > So it will never be part of any release by xorg then...
>
> Why would it need to be? GNOME and KDE are not part of xorg.
Sun have also implemented Composite as part of Xorg, and have some other
extensions to the server to support PLG.
--
Daniel Stone <[email protected]>
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/20040630/6a2ba45b/attach
ment.pgp
From Alan.Coopersmith at Sun.COM Tue Jun 29 11:19:41 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Tue Jun 29 11:19:44 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Torgeir Veimo wrote:
> On Tue, 2004-06-29 at 10:54 -0700, Alan Coopersmith wrote:
>
>>Project
>>Looking Glass has been submitted as an Open Source project on java.net
>>under the GNU Public License, or GPL.
>
>
> So it will never be part of any release by xorg then...
>
It doesn't need to be - the components in the Xserver itself are things like
the Composite and Damage extensions covered by standard X/MIT style licenses,
and mostly developed independently of Project Looking Glass.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From Alan.Coopersmith at Sun.COM Tue Jun 29 11:22:58 2004
From: Alan.Coopersmith at Sun.COM (Alan Coopersmith)
Date: Tue Jun 29 11:23:31 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Tue, Jun 29, 2004 at 02:08:03PM -0400, Alex Deucher wrote:
>
>>On Tue, 29 Jun 2004 19:04:06 +0100, Torgeir Veimo <[email protected]> wrote:
>>
>>>On Tue, 2004-06-29 at 10:54 -0700, Alan Coopersmith wrote:
>>>
>>>>Project
>>>>Looking Glass has been submitted as an Open Source project on java.net
>>>>under the GNU Public License, or GPL.
>>>
>>>So it will never be part of any release by xorg then...
>>
>>Why would it need to be? GNOME and KDE are not part of xorg.
>
>
> Sun have also implemented Composite as part of Xorg, and have some other
> extensions to the server to support PLG.
As noted on https://lg3d-x11.dev.java.net/ the components going into the
X server itself are standard X/MIT license.
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
From jonsmirl at yahoo.com Tue Jun 29 11:44:39 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Tue Jun 29 11:44:43 2004
Subject: [Xorg] Input device hotplug
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Kristian Høgsberg <[email protected]> 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.
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
From keithp at keithp.com Tue Jun 29 11:44:36 2004
From: keithp at keithp.com (Keith Packard)
Date: Tue Jun 29 11:44:53 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: Your message of "Tue, 29 Jun 2004 10:15:07 EDT."
<[email protected]>
Message-ID: <[email protected]>
Around 10 o'clock on Jun 29, Michael Frey wrote:
> KaaPixmapPriv (pPixmap);
> This is always returning NULL.
Did you set the KAA_OFFSCREEN_PIXMAPS bit in the flags?
> I also noticed that the macro
> KaaSetPixmapPriv(p,a)
> is never being called. How does the devPrivates get set for the pixmap?
The pixmap creation code automatically sets the devPrivates field for
preallocated per-pixmap data (that requested by AllocatePixmapPrivate).
Look at kaaDrawInit to see how that gets set up.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040629/1983d95b/attach
ment.pgp
From keithp at keithp.com Tue Jun 29 11:47:00 2004
From: keithp at keithp.com (Keith Packard)
Date: Tue Jun 29 11:47:26 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: Your message of "Tue, 29 Jun 2004 17:11:58 +0200."
<[email protected]>
Message-ID: <[email protected]>
Around 17 o'clock on Jun 29, Roland Mainz wrote:
> Does anyone know what is going wrong below:
Yeah, the CVS folks decided to change how scripts should be written and
didn't bother to make it backward compatible. So, we need to rewrite the
'commitcheck' script, but no-one has bothered yet.
You can safely ignore the warnings, or fix the script.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040629/bd2e451b/attach
ment.pgp
From daniel at freedesktop.org Tue Jun 29 11:50:09 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Tue Jun 29 11:50:11 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
Message-ID: <[email protected]>
On Tue, Jun 29, 2004 at 11:47:00AM -0700, Keith Packard wrote:
> Around 17 o'clock on Jun 29, Roland Mainz wrote:
> > Does anyone know what is going wrong below:
>
> Yeah, the CVS folks decided to change how scripts should be written and
> didn't bother to make it backward compatible. So, we need to rewrite the
> 'commitcheck' script, but no-one has bothered yet.
... right around the time they put out two releases in very, very close
proximity to each other, with a total of four security fixes. Sigh.
--
Daniel Stone <[email protected]>
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/20040630/bf8376e8/attach
ment-0001.pgp
From mfrey at pepper.com Tue Jun 29 11:52:49 2004
From: mfrey at pepper.com (Michael Frey)
Date: Tue Jun 29 11:52:52 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Yes,
I got it -- working now -- Thanks...
One item -- because I do not have much memory on my video card -- Using
the composite extension is very slow. I disabled it and the server
screams.
Michael
On Jun 29, 2004, at 2:44 PM, Keith Packard wrote:
>
> Around 10 o'clock on Jun 29, Michael Frey wrote:
>
>> KaaPixmapPriv (pPixmap);
>> This is always returning NULL.
>
> Did you set the KAA_OFFSCREEN_PIXMAPS bit in the flags?
>
>> I also noticed that the macro
>> KaaSetPixmapPriv(p,a)
>> is never being called. How does the devPrivates get set for the
>> pixmap?
>
> The pixmap creation code automatically sets the devPrivates field for
> preallocated per-pixmap data (that requested by AllocatePixmapPrivate).
>
> Look at kaaDrawInit to see how that gets set up.
>
> -keith
>
>
From keithp at keithp.com Tue Jun 29 11:56:58 2004
From: keithp at keithp.com (Keith Packard)
Date: Tue Jun 29 11:57:51 2004
Subject: [Xorg] The big multiconsole nasty
In-Reply-To: Your message of "Tue, 29 Jun 2004 16:15:52 BST."
<[email protected]>
Message-ID: <[email protected]>
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 ISA
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.
> 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.
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.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040629/449d8190/attach
ment.pgp
From Deron.Johnson at Sun.COM Tue Jun 29 12:03:09 2004
From: Deron.Johnson at Sun.COM (Deron Johnson)
Date: Tue Jun 29 12:02:23 2004
Subject: [Xorg] Project Looking Glass developer release source code is now
available
Message-ID: <[email protected]>
Sun opened the source code for the developer's release of Project
Looking Glass today. It is available on http://java.net in the lg3d
project. There are three subprojects:
lg3d-core The 3D related software
lg3d-demo-apps Example 3D applications
lg3d-x11 Modified X11 release
The people on this mailing list will probably be most interested in the
lg3d-x11 project. We opened this project on lg3d-x11 for the sake
of expediency, but we intend to eventually transfer it over into
freedesktop.org.
The lg3d-x11 project is still very much a work in progress.
To date, only a few X11 applications run bug-free. But we decided
to release now in order to bootstrap 3D application development.
There is still a lot of X11 debugging work left to do. Important
applications such as mozilla, staroffice, evolution, realplayer, and
most GNOME applications still have significant problems. We are actively
addressing these problems. Please file issues to
[email protected].
Special thanks to Keith Packard of HP for his excellent extensions:
Damage, Xfixes, and Composite. Although they were originally developed
with 2D in mind, they are exactly what is needed to make a 3D window
system based on X11. Without Keith's excellent work we could not have
been able to release Project Looking Glass so soon. Also, I would like
to offer my thanks to Sun's X team, especially Jay Cotton, Stuart
Kreitman, and Alan Coopersmith, for their invaluable assistance.
I would like to invite all X developers to check out the code and
to get involved in making Linux the premier platform for 3D
window system development.
-Deron Johnson
Project Looking Glass
[email protected]
(510) 996-7190
From keithp at keithp.com Tue Jun 29 12:06:40 2004
From: keithp at keithp.com (Keith Packard)
Date: Tue Jun 29 12:06:50 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: Your message of "Tue, 29 Jun 2004 14:52:49 EDT."
<[email protected]>
Message-ID: <[email protected]>
Around 14 o'clock on Jun 29, Michael Frey wrote:
> One item -- because I do not have much memory on my video card -- Using
> the composite extension is very slow. I disabled it and the server
> screams.
Life is hard for those of us with small video cards; you'll see us
clustered 'round the 512Mb video cards with envy in our eyes.
If you have an AGP card, and some documentation, it's not at all
inconceivable to use main memory from the accelerator to make Composite
scream as well.
Glad it's working.
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://freedesktop.org/pipermail/xorg/attachments/20040629/29047bcb/attach
ment.pgp
From Deron.Johnson at Sun.COM Tue Jun 29 12:12:41 2004
From: Deron.Johnson at Sun.COM (Deron Johnson)
Date: Tue Jun 29 12:11:55 2004
Subject: [Xorg] Re: Project Looking Glass developer release source code is
now available
References: <[email protected]>
Message-ID: <[email protected]>
The licensing model for the Project Looking Glass source is as follows:
1. lg3d-x11: all of the code in this project is MIT licensed.
2. lg3d-core: I needed to make some modifications to Keith's lightpipe
code. My modifications to this code are MIT licensed. The remainder
of lg3d-core is dual licensed. Developers can use the source under
the GPL license, or negotiate a commercial license with Sun.
So please note that all of the X11 server and client library work
that we will be doing as part of Project Looking Glass will be able
to be integrated into future releases of Xorg if that is what people
want to do.
Deron Johnson wrote:
>
> Sun opened the source code for the developer's release of Project
> Looking Glass today. It is available on http://java.net in the lg3d
> project. There are three subprojects:
>
> lg3d-core The 3D related software
> lg3d-demo-apps Example 3D applications
> lg3d-x11 Modified X11 release
>
> The people on this mailing list will probably be most interested in the
> lg3d-x11 project. We opened this project on lg3d-x11 for the sake
> of expediency, but we intend to eventually transfer it over into
> freedesktop.org.
>
> The lg3d-x11 project is still very much a work in progress.
> To date, only a few X11 applications run bug-free. But we decided
> to release now in order to bootstrap 3D application development.
> There is still a lot of X11 debugging work left to do. Important
> applications such as mozilla, staroffice, evolution, realplayer, and
> most GNOME applications still have significant problems. We are actively
> addressing these problems. Please file issues to
> [email protected].
>
> Special thanks to Keith Packard of HP for his excellent extensions:
> Damage, Xfixes, and Composite. Although they were originally developed
> with 2D in mind, they are exactly what is needed to make a 3D window
> system based on X11. Without Keith's excellent work we could not have
> been able to release Project Looking Glass so soon. Also, I would like
> to offer my thanks to Sun's X team, especially Jay Cotton, Stuart
> Kreitman, and Alan Coopersmith, for their invaluable assistance.
>
> I would like to invite all X developers to check out the code and
> to get involved in making Linux the premier platform for 3D
> window system development.
>
> -Deron Johnson
> Project Looking Glass
> [email protected]
> (510) 996-7190
>
>
From brian.paul at tungstengraphics.com Tue Jun 29 12:08:04 2004
From: brian.paul at tungstengraphics.com (Brian Paul)
Date: Tue Jun 29 12:14:27 2004
Subject: [Xorg] [Fwd: Project Looking Glass Open Source Announcement]
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
Alan Coopersmith wrote:
>
>
> -------- Original Message --------
> Subject: Project Looking Glass Open Source Announcement
> Date: Tue, 29 Jun 2004 10:46:06 -0700
> From: Lauren Zuravleff <[email protected]>
> Reply-To: [email protected]
> To: [email protected]
>
> Project Looking Glass Open Source
> ---------------------------------
> Sun Microsystems is contributing Project Looking Glass, based on
> Java(tm) technology, to the open source community. Project Looking Glass
> is an exploration project to bring innovative 3D features to the desktop
> environment. The desktop interface will offer an intuitive, new 3D
> environment to interact with desktop applications featuring window
> transparency, rotation, zoom, multiple desktop workspaces and
> miniaturization.Project Looking Glass offers a platform to realize far
> richer and more entertaining user experience for existing and new
> applications in 2D or 3D. The technology enables developers to build
> highly visual 3D desktops and applications that will run on Linux
> systems such as Sun's Java Desktop System. The Solaris(tm) environment
> will be supported in near future.
>
>
> What does this mean to you?
> ---------------------------
> If you're a software developer, please go to
> http://lg3d-core.dev.java.net and download this early version of the
> code and join the community in developing the 3D desktop.
>
> Interested in using the Project Looking Glass? The project is in very
> early stages and a commercial version is not available yet. Please go to
> http://www.sun.com/software/project-looking-glass to keep up to date on
> our progress.
Has anyone had luck with that URL? I've tried several times over the
past few days, but always get "wwws.sun.com could not be found" [sic].
-Brian
From jonsmirl at yahoo.com Tue Jun 29 12:14:30 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Tue Jun 29 12:14:32 2004
Subject: [Xorg] The big multiconsole nasty
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
--- Keith Packard <[email protected]> wrote:
> 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 ISA
> 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.
I have code that could be added to DRM that:
1) ioctl to make sure all VGA devices are disabled and remember the one
that was. It uses kernel calls to achieve this.
2) after disabling VGA devices run the user space reset program which
will enable VGA on the card being reset
3) ioctl the driver again to disable all VGAs and restore the original
one.
I think it would be better to just get the whole reset issue out of
xfree and into a separate hotplug app. fbdev needs reset support too.
> > 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.
>
> 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.
Xfree should never remap anything in PCI space. Moving things in PCI
space almost guarantees that a later hotplug event will mess up the
system. Moving things in PCI space should be done with kernel
utilities, not as part of Xfree.
>
> -keith
>
>
>
> ATTACHMENT part 1.2 application/pgp-signature
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
From jonsmirl at yahoo.com Tue Jun 29 12:16:30 2004
From: jonsmirl at yahoo.com (Jon Smirl)
Date: Tue Jun 29 12:16:33 2004
Subject: [Xorg] The big multiconsole nasty
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
You also need another ioctl for retrieving the contents of the video
ROM. xfree should not be enabling this from user space. There are
kernel calls for doing this that work with hotplug. I have code for
this ioctl too.
--- Keith Packard <[email protected]> wrote:
>
> 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 ISA
> 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.
>
> > 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.
>
> 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.
>
> -keith
>
>
>
> ATTACHMENT part 1.2 application/pgp-signature
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
=====
Jon Smirl
[email protected]
__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
From eta at lclark.edu Tue Jun 29 15:14:00 2004
From: eta at lclark.edu (Eric Anholt)
Date: Tue Jun 29 12:19:35 2004
Subject: [Xorg] debrix
In-Reply-To: <1088421789.17763.26.camel@localhost>
References: <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<[email protected]> <[email protected]>
<1088421789.17763.26.camel@localhost>
Message-ID: <1088526951.1134.8.camel@abbey>
On Mon, 2004-06-28 at 04:23, Michel D?nzer wrote:
> On Mon, 2004-06-28 at 13:06 +0200, Jakub Piotr C?apa wrote:
> > Daniel Stone wrote:
> > > On Mon, Jun 28, 2004 at 03:41:45AM +0200, Jakub Piotr C??apa wrote:
> > >
> > >>While building in a clear enviroment I've catched some other problems
> > >>(patch is available [1]) (ordered as fixes appear in the diff)
> >
> > Forgot about one - in
> > debrix/hw/xorg/os-support/shared/drm/kernel/drm.h there is an #include
> > of kernel config file. I'm pretty sure we should avoid this (and simply
> > removing this include semms to work... PLD has a patch for Xorg
> > monolitic tree that does no more than this and everything works fine).
>
> If this header file is indeed needed in userspace, the correct solution
> would be to wrap the kernel specific parts in
>
> #ifdef __KERNEL__
> ...
> #endif
>
> Not that this tree should build the DRM kernel modules at all (if the
> DRM code in the kernel is too old, get the current code from the DRI CVS
> drm module), but it might help merges.
This may be my lack of sleep, but the CONFIG_ usage seems to turn on
defines used only by userland, in the < XFree86 4.1.0 case.
Now, if I was in charge I'd say "let's not kid ourselves that we really
support compiling XFree86 < 4.1.0 with these headers" and axe it. If
that's not an option, it also seems like those defines about DRM_PROC_*
and DRM_DEV_* could be just always enabled with a warning in a comment
above of "this is deprecated, don't use it."
--
Eric Anholt [email protected]
http://people.freebsd.org/~anholt/ [email protected]
From daniel at freedesktop.org Tue Jun 29 12:21:17 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Tue Jun 29 12:21:18 2004
Subject: [Xorg] debrix
In-Reply-To: <1088526951.1134.8.camel@abbey>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<1088421789.17763.26.camel@localhost>
<1088526951.1134.8.camel@abbey>
Message-ID: <[email protected]>
On Tue, Jun 29, 2004 at 03:14:00PM -0700, Eric Anholt wrote:
> This may be my lack of sleep, but the CONFIG_ usage seems to turn on
> defines used only by userland, in the < XFree86 4.1.0 case.
>
> Now, if I was in charge I'd say "let's not kid ourselves that we really
> support compiling XFree86 < 4.1.0 with these headers" and axe it. If
> that's not an option, it also seems like those defines about DRM_PROC_*
> and DRM_DEV_* could be just always enabled with a warning in a comment
> above of "this is deprecated, don't use it."
Let's not kid ourselves that we really support compiling XFree86 < 4.1.0
with these headers.
--
Daniel Stone <[email protected]>
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/20040630/425654e7/attach
ment.pgp
From carl at personnelware.com Tue Jun 29 12:53:38 2004
From: carl at personnelware.com (Carl Karsten)
Date: Tue Jun 29 12:48:32 2004
Subject: [Xorg] tvout fedora2
References: <[email protected]>
Message-ID: <06d901c45e12$c6217440$1e01a8c0@cnt496>
> Can some one give an example of how xorg.conf should look like if i have intel
video board i810
> and i want to enable tv out?
I use this: http://www.maersk-moller.net/projects/familynet/TV-Out.html
Carl K
From chapuis at lri.fr Tue Jun 29 13:42:14 2004
From: chapuis at lri.fr (Olivier Chapuis)
Date: Tue Jun 29 13:44:14 2004
Subject: [Xorg] A 3D X Desktop
Message-ID: <[email protected]>
Hello,
Maybe some people can be interested by this experimental software:
http://insitu.lri.fr/~chapuis/metisse
It is a 3D X desktop based on Xvnc, XDarwin, FVWM and Ametista. There
is some code from the fdo xserver and xlibs (neither Damage, nor
Composite are used, but I started with fdo as it is modular and
autoconfiscated). So there is some code from XFree (before the license
change) and Xorg. There is also some code from VNC and TightVNC.
This project has not the same ambition than the "Sun Looking Glass
project". It is a project for conducting some experimentation.
However, almost all X11 applications work fine here (there is no GLX
support).
Regards, Olivier Chapuis
From jbarnes at engr.sgi.com Tue Jun 29 13:50:25 2004
From: jbarnes at engr.sgi.com (Jesse Barnes)
Date: Tue Jun 29 13:51:00 2004
Subject: [Xorg] Re: Xserver device I/O on Linux
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
On Friday, June 25, 2004 10:00 am, Jesse Barnes wrote:
> On Tuesday, May 4, 2004 1:30 pm, John Dennis wrote:
> > Both xfree86 and xorg on which it is based has code for using
> > /proc/bus/pci on linux, in fact when building for ia64 this is exactly
> > what happens so I'm a bit confused as to why you're having an issue with
> > ia64.
>
> ia64 doesn't, by default, build with PCI domain support. It defines
> INCLUDE_XF86_NO_DOMAIN which causes it to use /dev/mem for things. I'd
> like to change that.
>
> > We've been building and shipping X for ia64 for a while using this
> > code base. One change we recently made was to always use the linux
> > version of the pci routines on all architectures, it had been the case
> > that on x86 the pci code was accessing pci config space via the IO ports
> > and soon this won't be supported (pci express does not support it and
> > there are issues with concurrency on mp machines). This was a trival one
> > line change to an ifdef to use the linux code.
>
> So you removed the INCLUDE_XF86_NO_DOMAIN define?
>
> > I'm not sure what you mean by port I/O and mapping not being provided in
> > a way the server expects could you elaborate? A lot of these issues have
> > been addressed. But you're certainly right, port I/O on non-x86
> > architectures has been a nasty area.
>
> Here's a patch that might illustrate some of what I'm trying to do. There
> are several issues at play here:
>
> o Linux/ia64 kernel PCI domain support (I still need to do this properly,
> the attached patch is funky because PCIIOC_CONTROLLER isn't implemented
> in my kernel)
> o bus addr != host addr on some ia64 platforms, so X on ia64 needs to
> have pciBusAddrToHostAddr implemented, this should be easy with
> the /proc/bus/pci API
> o ia64Pci.c roots around in /dev/mem, which can cause MCAs on machines
> that don't have the addresses it's looking for, so some other mechanism for
> discovering which PCI bridge is present would be desirable
> o legacy port access isn't handled gracefully on some platforms, it
> causes master aborts. I've got a patch to the Linux/ia64 kernel which will
> recover from this condition and send offending apps a SIGBUS when this
> occurs, which seems to be working well enough for X to boot cards up
>
> So does anyone own hw/xorg/os-support in the new tree? If not, Shrijeet
> and I would be willing to help out...
Ugg, it looks like the attachment was truncated. Here it is inline for anyone
who wants to look.
Jesse
Index: hw/xorg/common/compiler.h
===================================================================
RCS file: /cvs/xserver/debrix/hw/xorg/common/compiler.h,v
retrieving revision 1.3
diff -u -r1.3 compiler.h
--- hw/xorg/common/compiler.h 10 Jun 2004 19:40:04 -0000 1.3
+++ hw/xorg/common/compiler.h 25 Jun 2004 14:42:23 -0000
@@ -465,10 +465,12 @@
# ifndef __INTEL_COMPILER
# define mem_barrier() __asm__ __volatile__ ("mf" ::: "memory")
# define write_mem_barrier() __asm__ __volatile__ ("mf" ::: "memory")
+# define io_mem_barrier() __asm__ __volatile__ ("mf.a" ::: "memory")
# else
# include "ia64intrin.h"
# define mem_barrier() __mf()
# define write_mem_barrier() __mf()
+# define io_mem_barrier() __mfa
# endif

/*
@@ -491,14 +493,132 @@
__mf();\
__isrlz();\
}
-# endif
+# endif /* __INTEL_COMPILER */
+
+/*
+ * It seems like the in/out routines in this file could be consolidated a bit
+ * and/or split into multiple, arch specific header files.
+ *
+ * Many also assume that the 'port' value passed in is an actual address,
+ * rather than relative to some 'IOBase' value. This means that callers
+ * have to be fixed up to get their own 'IOBase' (which will be PCI device
+ * specific), or the inX/outX routines need to be changed to take a PCI
+ * tag so that platforms can route the PIOs to the correct bus.
+ */
+
# undef outb
# undef outw
# undef outl
-
-# define outb(a,b) _outb(b,a)
-# define outw(a,b) _outw(b,a)
-# define outl(a,b) _outl(b,a)
+
+/*
+ * Deal with outX on platforms where it's simply a store.
+ */
+
+static inline unsigned int outb(unsigned long port, unsigned char val)
+{
+ volatile unsigned char *addr = (unsigned char *)port;
+
+ *addr = val;
+ io_memory_barrier();
+}
+
+static inline unsigned int outw(unsigned long port, unsigned short val)
+{
+ volatile unsigned short *addr = (unsigned char *)port;
+
+ *addr = val;
+ io_memory_barrier();
+}
+
+static inline unsigned int outl(unsigned long port, unsigned int val)
+{
+ volatile unsigned int *addr = (unsigned char *)port;
+
+ *addr = val;
+ io_memory_barrier();
+}
+
+# undef inb
+# undef inw
+# undef inl
+
+/*
+ * Deal with master aborts on a really funky platform. The kernel will send
+ * a SIGBUS to applications that have mapped /proc/bus/pci/... when an I/O
+ * error, like a master abort, occurs.
+ *
+ * On ia64, an error caused by an uncached read may (and probably will) be
+ * reported to software *way* after the instruction that did the read. The
+ * only way to be sure that any errors that might occur have been flushed out
+ * is to use the value we get back in a statement that affects control flow.
+ *
+ * Note that on some platforms, an PIO read does *not* guarantee that DMA
+ * initiated prior to the PIO is complete.
+ */
+extern int ia64_io_error;
+
+static inline unsigned int inb(unsigned long port)
+{
+ unsigned int val;
+
+ /* The SIGBUS handler will set this for us if an error occurs */
+ ia64_io_error = 0;
+
+ val = (unsigned int) (*((volatile unsigned char *)port));
+
+ /* Use val in an expression to flush out errors */
+ if (val && ia64_io_error)
+ return -1;
+
+ /* Double check for an error */
+ if (ia64_io_error)
+ return -1;
+
+ /* val was actually read from the hardware */
+ return val;
+}
+
+static inline unsigned int inw(unsigned long port)
+{
+ unsigned int val;
+
+ /* The SIGBUS handler will set this for us if an error occurs */
+ ia64_io_error = 0;
+
+ val = (unsigned int) (*((volatile unsigned short *)port));
+
+ /* Use val in an expression to flush out errors */
+ if (val && ia64_io_error)
+ return -1;
+
+ /* Double check for an error */
+ if (ia64_io_error)
+ return -1;
+
+ /* val was actually read from the hardware */
+ return val;
+}
+
+static inline unsigned int inl(unsigned long port)
+{
+ unsigned int val;
+
+ /* The SIGBUS handler will set this for us if an error occurs */
+ ia64_io_error = 0;
+
+ val = (unsigned int) (*((volatile unsigned int *)port));
+
+ /* Use val in an expression to flush out errors */
+ if (val && ia64_io_error)
+ return -1;
+
+ /* Double check for an error */
+ if (ia64_io_error)
+ return -1;
+
+ /* val was actually read from the hardware */
+ return val;
+}

# elif defined(linux) && defined(__amd64__)

Index: hw/xorg/os-support/bus/Pci.h
===================================================================
RCS file: /cvs/xserver/debrix/hw/xorg/os-support/bus/Pci.h,v
retrieving revision 1.3
diff -u -r1.3 Pci.h
--- hw/xorg/os-support/bus/Pci.h 10 Jun 2004 19:40:52 -0000 1.3
+++ hw/xorg/os-support/bus/Pci.h 25 Jun 2004 14:42:23 -0000
@@ -257,7 +257,6 @@
# if defined(linux)
# define ARCH_PCI_INIT linuxPciInit
# define INCLUDE_XF86_MAP_PCI_MEM
-# define INCLUDE_XF86_NO_DOMAIN
# elif defined(FreeBSD)
# define ARCH_PCI_INIT freebsdPciInit
# define INCLUDE_XF86_MAP_PCI_MEM
Index: hw/xorg/os-support/bus/ia64Pci.c
===================================================================
RCS file: /cvs/xserver/debrix/hw/xorg/os-support/bus/ia64Pci.c,v
retrieving revision 1.2
diff -u -r1.2 ia64Pci.c
--- hw/xorg/os-support/bus/ia64Pci.c 10 Jun 2004 19:40:52 -0000 1.2
+++ hw/xorg/os-support/bus/ia64Pci.c 25 Jun 2004 14:42:23 -0000
@@ -32,17 +32,37 @@
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
+#include <signal.h>
#include "460gxPCI.h"
#include "e8870PCI.h"
#include "zx1PCI.h"
#include "Pci.h"

+/* Used by the in/out routines to check for master aborts */
+int ia64_io_error;
+
+void ia64SigBusHandler(int signo, siginfo_t *sinfo, void *unused)
+{
+ ia64_io_error = 1;
+}
+
+void
+ia64SigBusSetup(void)
+{
+ struct sigaction saction;
+
+ saction.sa_sigaction = ia64SigBusHandler;
+ saction.sa_flags = SA_SIGINFO;
+ sigaction(SIGBUS, &saction, NULL);
+}
+
void
ia64ScanPCIWrapper(scanpciWrapperOpt flags)
{

if (flags == SCANPCI_INIT) {
-
+ ia64SigBusSetup();
+#if 0
/* PCI configuration space probes should be done first */
if (xf86PreScan460GX())
return;
@@ -50,13 +70,13 @@
return;
if (xf86PreScanZX1())
return;
-
+#endif
} else /* if (flags == SCANPCI_TERM) */ {
-
+#if 0
xf86PostScan460GX();
xf86PostScanE8870();
xf86PostScanZX1();
-
+#endif
}

}
Index: hw/xorg/os-support/bus/linuxPci.c
===================================================================
RCS file: /cvs/xserver/debrix/hw/xorg/os-support/bus/linuxPci.c,v
retrieving revision 1.3
diff -u -r1.3 linuxPci.c
--- hw/xorg/os-support/bus/linuxPci.c 10 Jun 2004 19:40:52 -0000 1.3
+++ hw/xorg/os-support/bus/linuxPci.c 25 Jun 2004 14:42:23 -0000
@@ -327,7 +327,8 @@
if (pPCI && (result = PCI_DOM_FROM_BUS(pPCI->busnum)))
return result;

- if ((fd = linuxPciOpenFile(pPCI ? pPCI->tag : 0)) < 0)
+ /* Open the bridge if present, otherwise try this device */
+ if ((fd = linuxPciOpenFile(pPCI ? pPCI->tag : Tag)) < 0)
return 0;

if ((result = ioctl(fd, PCIIOC_CONTROLLER, 0)) < 0)
@@ -350,7 +351,8 @@

pPCI = xf86GetPciHostConfigFromTag(Tag);

- if (((fd = linuxPciOpenFile(pPCI ? pPCI->tag : 0)) < 0) ||
+ /* Again, use the tag we were given if there's no parent bridge */
+ if (((fd = linuxPciOpenFile(pPCI ? pPCI->tag : Tag)) < 0) ||
(ioctl(fd, mmap_ioctl, 0) < 0))
break;

From mfrey at pepper.com Tue Jun 29 14:37:36 2004
From: mfrey at pepper.com (Michael Frey)
Date: Tue Jun 29 14:37:39 2004
Subject: [Xorg] Font problems...
Message-ID: <[email protected]>
Maybe someone can help me out on this one.
I am running the new kdrive server and all is well when running mozilla
and other apps. When I try to run the gtk-demo my fonts do not work.
I tried running fc-cache -fv and still nothing.
The interesting part is that mozilla was built using the gtk2 toolkit
and that works but not the gtk demo program. The program runs but all
I get is squares where text should be.
As a note the gtk-demo program does work when using the kdrive server
from the XFree86 tree.
Any ideas?
Michael
From aritger at nvidia.com Tue Jun 29 15:25:46 2004
From: aritger at nvidia.com (Andy Ritger)
Date: Tue Jun 29 15:28:00 2004
Subject: [Xorg] Xfbdev acceleration without offscreen pixmaps?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Tue, 29 Jun 2004, Keith Packard wrote:
>
> Around 14 o'clock on Jun 29, Michael Frey wrote:
>
> > One item -- because I do not have much memory on my video card --
> Using
> > the composite extension is very slow. I disabled it and the server
> > screams.
>
> Life is hard for those of us with small video cards; you'll see us
> clustered 'round the 512Mb video cards with envy in our eyes.
Please be careful when counting on large vidmem configurations for
Composite support. As the amount of video memory increases, less
of it will be mappable for direct CPU accesses (due to exhausting
address space, SBIOS compatibility issues, etc).
In our experiments, we found many SBIOSes failed to even boot with
a graphics board strapped for 512 Mb of video memory, even with
low system memory populations. And of course, as the amount of
video memory + system memory configurations increase, mapping all
memory will quickly exhaust a 32 bit address space.

For >= 512Mb video cards, we're most likely going to only strap
them at some smaller size (a likely config will be 512 real/256
strapped). The rest of vidmem will of course be accessible via
the GPU, but not accessible directly by the CPU.

This most likely doesn't have a huge impact on Composite, but it
will mean that we can't count on sw rendering to all redirected
windows (or, limit redirected windows to the mappable region of
vidmem). Of course, the solution will be for large vidmem drivers
to add paths such that all rendering is done via the GPU.
Just FYI.
Thanks,
- Andy
> If you have an AGP card, and some documentation, it's not at all
> inconceivable to use main memory from the accelerator to make Composite
> scream as well.
>
> Glad it's working.
>
> -keith
>
>
>
>
From elylevy-xserver at cs.huji.ac.il Wed Jun 30 02:07:01 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Jun 30 02:07:05 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
When I converted it to the new format I added the 1 there cause the
commit email script doesn't support the old format, checking their site
there still isn't a version compatbile with the new one.
but should probebly be one soon and then we can get rid of all those silly
warnings.
btw for guys who didn't know I added cia's commit script and now there is
an irc channel called #fdo-commits , I added most of the x related
projects, but still I think xkb*/xcb/hal/dbus are missing, or if there is
any other project who is intrested, for those who doesn't use irc but like
RSS there is also http://cia.navi.cx/stats/host/freedesktop.org/.rss ;)
thanks to the great work of the CIA guys:)
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 30 Jun 2004, Daniel Stone wrote:
> On Tue, Jun 29, 2004 at 05:11:58PM +0200, Roland Mainz wrote:
> >
> > Hi!
> >
> > ----
> >
> > Does anyone know what is going wrong below:
> > -- snip --
> > cvs commit: warning: commitinfo line contains no format strings:
> > "/cvs/xorg/CVSROOT/commitcheck"
> > Appending defaults (" %r/%p %s"), but please be aware that this usage is
> > deprecated.
> > cvs commit: warning: commitinfo line contains no format strings:
> > "/cvs/xorg/CVSROOT/commitcheck"
> > Appending defaults (" %r/%p %s"), but please be aware that this usage is
> > deprecated.
> > /cvs/xorg/xc/ChangeLog,v <-- ChangeLog
> > new revision: 1.76; previous revision: 1.75
> > 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.
> > /cvs/xorg/xc/extras/Mesa/src/mesa/main/imports.h,v <-- imports.h
> > new revision: 1.2; previous revision: 1.1
> > 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.
> > Mailing the commit message to [email protected]...
> > -- snip --
> >
> > ... it seems the commit is working properly, but somehow I don't like
> > the warnings above. Is there a way to get rid of them ?
>
> 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.
>
> --
> Daniel Stone <[email protected]
g>
> freedesktop.org: powering your desktop http://www.freedesktop.o
rg
>
From brian.paul at tungstengraphics.com Wed Jun 30 07:48:21 2004
From: brian.paul at tungstengraphics.com (Brian Paul)
Date: Wed Jun 30 07:54:27 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
Daniel Stone wrote:
> On Tue, Jun 29, 2004 at 05:11:58PM +0200, Roland Mainz wrote:
>
>>Hi!
>>
>>----
>>
>>Does anyone know what is going wrong below:
>>-- snip --
>>cvs commit: warning: commitinfo line contains no format strings:
>> "/cvs/xorg/CVSROOT/commitcheck"
>>Appending defaults (" %r/%p %s"), but please be aware that this usage is
>>deprecated.
>>cvs commit: warning: commitinfo line contains no format strings:
>> "/cvs/xorg/CVSROOT/commitcheck"
>>Appending defaults (" %r/%p %s"), but please be aware that this usage is
>>deprecated.
>>/cvs/xorg/xc/ChangeLog,v <-- ChangeLog
>>new revision: 1.76; previous revision: 1.75
>>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.
>>/cvs/xorg/xc/extras/Mesa/src/mesa/main/imports.h,v <-- imports.h
>>new revision: 1.2; previous revision: 1.1
>>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.
>>Mailing the commit message to [email protected]...
>>-- snip --
>>
>>... it seems the commit is working properly, but somehow I don't like
>>the warnings above. Is there a way to get rid of them ?
>
>
> 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.
I think that whoever updated the CVS software should have updated the
scripts too.
-Brian
From eich at pdx.freedesktop.org Wed Jun 30 08:28:21 2004
From: eich at pdx.freedesktop.org (Egbert Eich)
Date: Wed Jun 30 08:29:31 2004
Subject: [Xorg] VSW4 test suite
In-Reply-To: [email protected] wrote on Tuesday,
29 June 2004 at 05:20:19 -0400
References: <[email protected]>
<Pine.LNX.4.56.0406290518560.1976@localhost>
Message-ID: <[email protected]>
Stuart Anderson writes:
> On Mon, 28 Jun 2004, Egbert Eich wrote:
>
> > If someone could give me a pointer to the (original) sources I
> > would take care of adding it to CVS and put up some documentation.
>
> We have prebuilt versions of the test suite currently located at
>
> http://ftp.freestandards.org/pub/lsb/test_suites/beta/binary/runtime/
>
> This is currently configured to test the liobraries against Xvfb, but it
> would only take 1 or 2 steps to change it to run against whatever server
> you wanted to test.
>
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.
Cheers,
Egbert.
From anderson at netsweng.com Wed Jun 30 08:39:48 2004
From: anderson at netsweng.com (Stuart Anderson)
Date: Wed Jun 30 08:39:56 2004
Subject: [Xorg] VSW4 test suite
In-Reply-To: <[email protected]>
References: <[email protected]>
<Pine.LNX.4.56.0406290518560.1976@localhost>
<[email protected]>
Message-ID: <Pine.LNX.4.56.0406301138000.1629@localhost>
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 for
building it, we could easily add one.
Stuart
Stuart R. Anderson [email protected]
Network & Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149
From mfrey at pepper.com Wed Jun 30 08:42:48 2004
From: mfrey at pepper.com (Michael Frey)
Date: Wed Jun 30 08:42:51 2004
Subject: [Xorg] Added support for touchscreen right mouse click in kdrive
(tslib)
Message-ID: <[email protected]>
I have added some code to support a press and hold right mouse click
for touch screens.
In order to get a right mouse click just press and hold on the screen
for about 1 second.
I have attached the file tslib.c.
If it is of interest.
Michael Frey
-------------- next part --------------
/*
* $RCSId: xc/programs/Xserver/hw/kdrive/linux/tslib.c,v 1.1 2002/11/01 22:27:49
keithp Exp $
* TSLIB based touchscreen driver for TinyX
* Derived from ts.c by Keith Packard
* Derived from ps2.c by Jim Gettys
*
* Copyright © 1999 Keith Packard
* Copyright © 2000 Compaq Computer Corporation
* Copyright © 2002 MontaVista Software Inc.
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of Keith Packard or Compaq not be used in
* advertising or publicity pertaining to distribution of the software without
* specific, written prior permission. Keith Packard and Compaq makes no
* representations about the suitability of this software for any purpose. It
* is provided "as is" without express or implied warranty.
*
* KEITH PACKARD AND COMPAQ DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
* SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS,
* IN NO EVENT SHALL KEITH PACKARD BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that
* copyright notice and this permission notice appear in supporting
* documentation, and that the name of Michael Taht or MontaVista not be used in
* advertising or publicity pertaining to distribution of the software without
* specific, written prior permission. Michael Taht and Montavista make no
* representations about the suitability of this software for any purpose. It
* is provided "as is" without express or implied warranty.
*
* MICHAEL TAHT AND MONTAVISTA DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
* SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS,
* IN NO EVENT SHALL EITHER BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
* PERFORMANCE OF THIS SOFTWARE.
*/
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
#define NEED_EVENTS
#include <X11/X.h>
#include <X11/Xproto.h>
#include <X11/Xpoll.h>
#include "inputstr.h"
#include "scrnintstr.h"
#include "kdrive.h"
#include <sys/ioctl.h>
#include <tslib.h>
static long lastx = 0, lasty = 0;
static struct tsdev *tsDev = NULL;
void (*tslib_raw_event_hook)(int x, int y, int pressure, void *closure);
void *tslib_raw_event_closure;
int KdTsPhyScreen = 0;
int samples, previousx, previousy = 0;
static void
TsRead (int tsPort, void *closure)
{
KdMouseInfo *mi = closure;
struct ts_sample event;
int n;
long x, y;
unsigned long flags;
if (tslib_raw_event_hook)
{
if (ts_read_raw(tsDev, &event, 1) == 1)
{
tslib_raw_event_hook (event.x, event.y, event.pressure, tslib_raw_ev
ent_closure);
}
return;
}
n = ts_read(tsDev, &event, 1);
if (n == 1)
{
if (event.pressure)
{
/*
* HACK ATTACK. (static global variables used !)
* Here we test for the touch screen driver actually being on the
* touch screen, if it is we send absolute coordinates. If not,
* then we send delta's so that we can track the entire vga screen.
*/
if (KdCurScreen == KdTsPhyScreen) {
if ((previousx == event.x) && (previousy == event.y)) {
samples++;
//ErrorF("-->Samples: %d\n",samples);
if (samples >= 5) {
//ErrorF("Sending Right Mouse Button\n");
flags = KD_BUTTON_3;
} else {
flags = KD_BUTTON_1;
}
} else {
samples = 0;
flags = KD_BUTTON_1;
//ErrorF("Sending Left Mouse Button\n");
}
x = event.x;
y = event.y;
previousx = event.x;
previousy = event.y;
} else {
flags = /* KD_BUTTON_1 |*/ KD_MOUSE_DELTA;
if ((lastx == 0) || (lasty == 0)) {
x = 0;
y = 0;
} else {
x = event.x - lastx;
y = event.y - lasty;
}
lastx = event.x;
lasty = event.y;
}
} else {
flags = KD_MOUSE_DELTA;
x = 0;
y = 0;
lastx = 0;
lasty = 0;
}
KdEnqueueMouseEvent (mi, flags, x, y);
}
}
static char *TsNames[] = {
NULL,
"/dev/touchscreen/ucb1x00",
"/dev/ts",
"/dev/touchscreen/0",
};
#define NUM_TS_NAMES (sizeof (TsNames) / sizeof (TsNames[0]))
int TsInputType;
static int
TslibEnable (int not_needed_fd, void *closure)
{
KdMouseInfo *mi = closure;
int fd = 0;
fprintf(stderr, "%s() called\n", __func__);
if(!(tsDev = ts_open(mi->name, 0))) {
fprintf(stderr, "%s() failed to open %s\n", __func__, mi->name );
return -1; /* XXX Not sure what to return here */
}

ts_config(tsDev);
fd=ts_fd(tsDev);
return fd;
}
static void
TslibDisable (int fd, void *closure)
{
ts_close(tsDev);
}
static int
TslibInit (void)
{
int i, j = 0;
KdMouseInfo *mi, *next;
int fd= 0;
int n = 0;
if (!TsInputType)
TsInputType = KdAllocInputType ();
for (mi = kdMouseInfo; mi; mi = next)
{
next = mi->next;
if (mi->inputType)
continue;
/* Check for tslib env var device setting */
if ((TsNames[0] = getenv("TSLIB_TSDEVICE")) == NULL)
j++;
if (!mi->name)
{
for (i = j; i < NUM_TS_NAMES; i++)
{
/* XXX Should check for */
if(!(tsDev = ts_open(TsNames[i],0))) continue;
ts_config(tsDev);
fd=ts_fd(tsDev);
if (fd >= 0)
{
mi->name = KdSaveString (TsNames[i]);
break;
}
}
} else {
if(!(tsDev = ts_open(mi->name,0)))
continue;
ts_config(tsDev);
fd=ts_fd(tsDev);
}
if (fd > 0 && tsDev != 0)
{
mi->driver = (void *) fd;
mi->inputType = TsInputType;
if (KdRegisterFd (TsInputType, fd, TsRead, (void *) mi))
n++;
/* Set callbacks for vt switches etc */
KdRegisterFdEnableDisable (fd, TslibEnable, TslibDisable);
}
else
{
fprintf(stderr, "%s() failed to open tslib\n", __func__);
if (fd > 0) close(fd);
}
}
return n;
}
static void
TslibFini (void)
{
KdMouseInfo *mi;
KdUnregisterFds (TsInputType, TRUE);
for (mi = kdMouseInfo; mi; mi = mi->next)
{
if (mi->inputType == TsInputType)
{
if(mi->driver) ts_close(tsDev);
mi->driver = 0;
mi->inputType = 0;
}
}
}
KdMouseFuncs TsFuncs = {
TslibInit,
TslibFini
};
From mfrey at pepper.com Wed Jun 30 11:23:28 2004
From: mfrey at pepper.com (Michael Frey)
Date: Wed Jun 30 11:23:31 2004
Subject: [Xorg] XCalibrate extension?
Message-ID: <[email protected]>
Is there an existing client application that makes use of the
XCalibrate extension?
If not how does one use this extension to re-calibrate on the fly?
Thanks,
Michael
From elylevy-xserver at cs.huji.ac.il Wed Jun 30 12:17:22 2004
From: elylevy-xserver at cs.huji.ac.il (Ely Levy)
Date: Wed Jun 30 12:17:26 2004
Subject: [Xorg] XCalibrate extension?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
calibrate?like Rander does?
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Wed, 30 Jun 2004, Michael Frey wrote:
> Is there an existing client application that makes use of the
> XCalibrate extension?
>
> If not how does one use this extension to re-calibrate on the fly?
>
> Thanks,
> Michael
>
>
> _______________________________________________
> xorg mailing list
> [email protected]
> http://freedesktop.org/mailman/listinfo/xorg
>
From mfrey at pepper.com Wed Jun 30 12:18:24 2004
From: mfrey at pepper.com (Michael Frey)
Date: Wed Jun 30 12:28:10 2004
Subject: [Xorg] XCalibrate extension?
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Message-ID: <[email protected]>
I mean re-calibrate a touch screen.
On Jun 30, 2004, at 3:17 PM, Ely Levy wrote:
> calibrate?like Rander does?
>
> Ely Levy
> System group
> Hebrew University
> Jerusalem Israel
>
>
>
> On Wed, 30 Jun 2004, Michael Frey wrote:
>
>> Is there an existing client application that makes use of the
>> XCalibrate extension?
>>
>> If not how does one use this extension to re-calibrate on the fly?
>>
>> Thanks,
>> Michael
>>
>>
>> _______________________________________________
>> xorg mailing list
>> [email protected]
>> http://freedesktop.org/mailman/listinfo/xorg
>>
From krahn at niehs.nih.gov Wed Jun 30 13:43:33 2004
From: krahn at niehs.nih.gov (Joe Krahn)
Date: Wed Jun 30 13:44:12 2004
Subject: [Xorg] XCalibrate extension?
In-Reply-To: <[email protected]>
References: <[email protected]> <Pine.LNX.4.56.0
[email protected]>
<[email protected]>
Message-ID: <[email protected]>
What is the XCalibrate extension??
If it is intended to adjust input devices, then it should be
incorporated into XINPUT. We don't need another extension when
all that is needed is to 'finish' designing XINPUT, which
is an unfinished work in terms of device control.
If it's for adjusting screen resolutions, it seems like that
should be part of the RANDR extension.
Joe Krahn
Michael Frey wrote:
> I mean re-calibrate a touch screen.
>
> On Jun 30, 2004, at 3:17 PM, Ely Levy wrote:
>
>> calibrate?like Rander does?
>>
>> Ely Levy
>> System group
>> Hebrew University
>> Jerusalem Israel
>>
>>
>>
>> On Wed, 30 Jun 2004, Michael Frey wrote:
>>
>>> Is there an existing client application that makes use of the
>>> XCalibrate extension?
>>>
>>> If not how does one use this extension to re-calibrate on the fly?
>>>
>>> Thanks,
>>> Michael
From alan at lxorguk.ukuu.org.uk Wed Jun 30 15:06:39 2004
From: alan at lxorguk.ukuu.org.uk (Alan Cox)
Date: Wed Jun 30 16:09:43 2004
Subject: [Xorg] The big multiconsole nasty
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
On Maw, 2004-06-29 at 20:14, Jon Smirl wrote:
> I have code that could be added to DRM that:
> 1) ioctl to make sure all VGA devices are disabled and remember the one
> that was. It uses kernel calls to achieve this.
> 2) after disabling VGA devices run the user space reset program which
> will enable VGA on the card being reset
> 3) ioctl the driver again to disable all VGAs and restore the original
> one.
Not sure it belongs in DRI but clearly it belongs somewhere. I'm looking
forward to seeing all this at the kernel/desktop summit
> I think it would be better to just get the whole reset issue out of
> xfree and into a separate hotplug app. fbdev needs reset support too.
As does ACPI resume. It certainly seems to make sense to do the BIOS
boot of all present VGA cards (or some kind of 'safe list' of ids)
at boot up.
From daniel at freedesktop.org Wed Jun 30 20:24:46 2004
From: daniel at freedesktop.org (Daniel Stone)
Date: Wed Jun 30 20:24:48 2004
Subject: [Xorg] CVS warnings at commit...
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
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 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.
--
Daniel Stone <[email protected]>
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/20040701/03228771/attach
ment.pgp
From plazmatikz_nz at myrealbox.com Wed Jun 30 22:47:22 2004
From: plazmatikz_nz at myrealbox.com (Mike Russell)
Date: Thu Jul 1 00:13:55 2004
Subject: [Xorg] sed errors with --enable-xorgserver
Message-ID: <[email protected]>
Hi i am trying to build xserver but
whenever i give it --enable-xorgserver It generates these errors during
configure and makes blank makefiles.
~Mike
checking for X11/XF86keysym.h... no
checking if unaligned word accesses behave as expected... yes
configure: creating ./config.status
config.status: creating Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
config.status: creating GL/Makefile
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
config.status: creating GL/glx/Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
config.status: creating GL/mesa/Makefile
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
config.status: creating include/Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
config.status: creating dix/Makefile
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
config.status: creating dri/Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
config.status: creating drm/Makefile
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
config.status: creating fb/Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
config.status: creating mi/Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
config.status: creating miext/Makefile
sed: file ./confstat901pH4/subs-4.sed line 51: Unterminated `s' command
sed: file ./confstat901pH4/subs-5.sed line 3: Unknown command: ``-''
From fcatrin at tuxpan.com Fri Jun 18 07:25:24 2004
From: fcatrin at tuxpan.com (Franco Catrin L.)
Date: Tue Jul 20 11:35:53 2004
Subject: [Xorg] To start Xvesa with WM how?
In-Reply-To: <[email protected]>
References: <[email protected]>
Message-ID: <[email protected]>
El jue, 17-06-2004 a las 18:27, Asterius Pandoras escribi?:
> Can anyone point me to code to start Xvesa ( or Xfbdev ) with Windows
> Manager? Thanks.
This is a simple, but insecure way to do it:
export DISPLAY=:1.0
./Xvesa :1 -ac -mode whateveryouwant & metacity & xterm
That will run the xserver as display 1 and it will run metacity and
xterm on it.
You can replace metacity by any window manager, or session manager
(gnome-session for example).
Another thing that you can do is to modify your (x|g|k)dm settings to
use Xvesa instead of the regular X.
--
Franco Catrin L.
http://www.tuxpan.com/fcatrin