0 Bewertungen0% fanden dieses Dokument nützlich (0 Abstimmungen)
272 Ansichten397 Seiten
X -configure : returns wrong results vor Hor. / Vert Refresh Rate on different monitors. This happens with monitors from belinea, Dell end else. Manuelly fixing the file works, but I need to create x configurations on the fly.
X -configure : returns wrong results vor Hor. / Vert Refresh Rate on different monitors. This happens with monitors from belinea, Dell end else. Manuelly fixing the file works, but I need to create x configurations on the fly.
X -configure : returns wrong results vor Hor. / Vert Refresh Rate on different monitors. This happens with monitors from belinea, Dell end else. Manuelly fixing the file works, but I need to create x configurations on the fly.
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: <200406011735.30591.dirk.westfal@frankfurter-verein.de> 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> <4644.217.10.252.50.1086099134.squirrel@mail.cacad.com> 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: <20040601110002.rPMtQyVmcZ@e-ticket-marketing.com> 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^OeNZIv@e-ticket-marketing.com> 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: <20040602074952.GH49097@ajax.noc.ntua.gr> 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: <40BDA61B.8020802@tlen.pl> 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: <40BDA61B.8020802@tlen.pl> References: <40BDA61B.8020802@tlen.pl> Message-ID: <Pine.LNX.4.56.0406021347340.18727@inferno-01.cs.huji.ac.il> 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 > xorg@freedesktop.org > 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: <Pine.LNX.4.56.0406021347340.18727@inferno-01.cs.huji.ac.il> References: <40BDA61B.8020802@tlen.pl> <Pine.LNX.4.56.0406021347340.18727@inferno-01.cs.huji.ac.il> Message-ID: <20040602112705.GA19583@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <mailman.22.1086182069.6724.xorg@freedesktop.org> 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: <20040602112705.GA19583@fooishbar.org> References: <40BDA61B.8020802@tlen.pl> <Pine.LNX.4.56.0406021347340.18727@inferno-01.cs.huji.ac.il> <20040602112705.GA19583@fooishbar.org> Message-ID: <Pine.LNX.4.56.0406021626500.20687@grok.cs.huji.ac.il> > > 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: <20040602112705.GA19583@fooishbar.org> References: <40BDA61B.8020802@tlen.pl> <Pine.LNX.4.56.0406021347340.18727@inferno-01.cs.huji.ac.il> <20040602112705.GA19583@fooishbar.org> Message-ID: <40BDD7E6.7040702@sun.com> 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: <Pine.SOL.4.44.0406021428290.6820-100000@inchkeith.ma.hw.ac.uk> 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: <20040602074952.GH49097@ajax.noc.ntua.gr> References: <20040602074952.GH49097@ajax.noc.ntua.gr> Message-ID: <1086185184.7761.8.camel@shaman.txp> 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 (nveber@jochen-stenzel.de) Date: Wed Jun 2 08:07:24 2004 Subject: [Xorg] ek In-Reply-To: <790FE70AK0E4H7GD@freedesktop.org> References: <790FE70AK0E4H7GD@freedesktop.org> Message-ID: <08JGL70K89KCJ2G2@jochen-stenzel.de> 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 (jamainlbbbsdef@yahoo.com) Date: Wed Jun 2 08:45:21 2004 Subject: [Xorg] Information Message-ID: <mailman.23.1086191121.6724.xorg@freedesktop.org> 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: <40BDA61B.8020802@tlen.pl> References: <40BDA61B.8020802@tlen.pl> 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 > xorg@freedesktop.org > 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: <40BE1138.2090100@eutonian.com> 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: <20040602112705.GA19583@fooishbar.org> References: <40BDA61B.8020802@tlen.pl> <Pine.LNX.4.56.0406021347340.18727@inferno-01.cs.huji.ac.il> <20040602112705.GA19583@fooishbar.org> Message-ID: <49262.152.2.178.68.1086218062.squirrel@spidermail.richmond.edu> 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 (higgins@ucc.ie) Date: Wed Jun 2 16:49:02 2004 Subject: [Xorg] Information Message-ID: <mailman.24.1086220142.6724.xorg@freedesktop.org> 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 (spt@parliament.go.ug) Date: Thu Jun 3 02:08:56 2004 Subject: [Xorg] (no subject) Message-ID: <1086253818.40beeafa42d7a@mail.parliament.go.ug> 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 (spt@parliament.go.ug) Date: Thu Jun 3 02:08:59 2004 Subject: [Xorg] (no subject) Message-ID: <1086253819.40beeafb51be5@mail.parliament.go.ug> 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 (slb5w@hotmail.com) Date: Thu Jun 3 09:12:23 2004 Subject: [Xorg] Hello Message-ID: <mailman.25.1086279143.6724.xorg@freedesktop.org> 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 (jpinfo@invitrogen.com) Date: Thu Jun 3 09:58:48 2004 Subject: [Xorg] Document Message-ID: <mailman.26.1086281928.6724.xorg@freedesktop.org> 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 (xorg@freedesktop.org) Date: Thu Jun 3 12:48:39 2004 Subject: [Xorg] Information Message-ID: <mailman.27.1086292119.6724.xorg@freedesktop.org> 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: <1086253818.40beeafa42d7a@mail.parliament.go.ug> References: <1086253818.40beeafa42d7a@mail.parliament.go.ug> Message-ID: <1086292321.11046.81.camel@shaman.txp> El jue, 03-06-2004 a las 05:10, spt@parliament.go.ug 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 (mnaqxxakjc@tuffmail.com) Date: Thu Jun 3 14:48:43 2004 Subject: [Xorg] Document Message-ID: <mailman.28.1086299323.6724.xorg@freedesktop.org> 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: <20040604144328.7aca3276.glennm@hydrix.com> 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 (newsletter@zipzoomfly.com) Date: Fri Jun 4 10:06:33 2004 Subject: [Xorg] Information Message-ID: <mailman.29.1086368793.6724.xorg@freedesktop.org> 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: <2846660.1086381419949.JavaMail.dpw2@njit.edu> 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: <200406042049.i54Knw407778@magic.shiman.com> 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: <2846660.1086381419949.JavaMail.dpw2@njit.edu> References: <2846660.1086381419949.JavaMail.dpw2@njit.edu> Message-ID: <40C0E5A4.7070000@Sun.COM> 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- alan.coopersmith@sun.com 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: <1086395853.7460.197809208@webmail.messagingengine.com> 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: <40C1B8D4.8030207@free.fr> 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: <200406051849.38144.AthaV@gmx.net> 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: <20040605193000.4c96027e.thecoop@runbox.com> 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: <2846660.1086381419949.JavaMail.dpw2@njit.edu> <40C0E5A4.7070000@Sun.COM> Message-ID: <40C2237E.36D35A95@nrubsig.org> 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <40C2237E.36D35A95@nrubsig.org> References: <2846660.1086381419949.JavaMail.dpw2@njit.edu> <40C0E5A4.7070000@Sun.COM> <40C2237E.36D35A95@nrubsig.org> Message-ID: <40C2262A.5090509@sun.com> 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- alan.coopersmith@sun.com 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: <200406052315.09437.clee@freedesktop.org> 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: <40C30BCE.5010508@st.hanze.nl> 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: <40C30BCE.5010508@st.hanze.nl> References: <40C30BCE.5010508@st.hanze.nl> Message-ID: <20040606221639.G65422@w3.cs.huji.ac.il> 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 > xorg@freedesktop.org > 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: <200406062157.58543.gio.grifis@fastwebnet.it> ...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 (max.muermann@logicacmg.com) Date: Sun Jun 6 18:00:54 2004 Subject: [Xorg] 'nv' driver, autotooled for xserver In-Reply-To: <200406052315.09437.clee@freedesktop.org> References: <200406052315.09437.clee@freedesktop.org> Message-ID: <200406071100.39045.max.muermann@logicacmg.com> 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 > xorg@freedesktop.org > 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: <40C3B756.9060006@wam.umd.edu> 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 xdg@freedesktop.org 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: elylevy@cs.huji.ac.il wrote on Sunday, 6 June 2004 at 22:18:20 +0300 References: <40C30BCE.5010508@st.hanze.nl> <20040606221639.G65422@w3.cs.huji.ac.il> Message-ID: <16580.18293.951487.646134@xf11.fra.suse.de> 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: <16580.18293.951487.646134@xf11.fra.suse.de> References: <40C30BCE.5010508@st.hanze.nl> <20040606221639.G65422@w3.cs.huji.ac.il> <16580.18293.951487.646134@xf11.fra.suse.de> Message-ID: <Pine.LNX.4.56.0406071439450.1130@gx-62.cs.huji.ac.il> 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: <16580.18293.951487.646134@xf11.fra.suse.de> Message-ID: <20040607123621.91705.qmail@web50104.mail.yahoo.com> --- Egbert Eich <eich@freedesktop.org> 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: <Pine.LNX.4.56.0406071439450.1130@gx-62.cs.huji.ac.il> References: <40C30BCE.5010508@st.hanze.nl> <20040606221639.G65422@w3.cs.huji.ac.il> <16580.18293.951487.646134@xf11.fra.suse.de> <Pine.LNX.4.56.0406071439450.1130@gx-62.cs.huji.ac.il> Message-ID: <20040607130115.GV21062@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040607123621.91705.qmail@web50104.mail.yahoo.com> References: <20040607123621.91705.qmail@web50104.mail.yahoo.com> Message-ID: <1086616171.31779.2.camel@support02.civic.twp.ypsilanti.mi.us> 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 > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg -- Sean Middleditch <elanthis@awesomeplay.com> 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: <20040607130115.GV21062@fooishbar.org> References: <40C30BCE.5010508@st.hanze.nl> <20040606221639.G65422@w3.cs.huji.ac.il> <16580.18293.951487.646134@xf11.fra.suse.de> <Pine.LNX.4.56.0406071439450.1130@gx-62.cs.huji.ac.il> <20040607130115.GV21062@fooishbar.org> Message-ID: <Pine.LNX.4.56.0406071718410.2123@gx-61.cs.huji.ac.il> > > 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: <Pine.LNX.4.56.0406071718410.2123@gx-61.cs.huji.ac.il> References: <40C30BCE.5010508@st.hanze.nl> <20040606221639.G65422@w3.cs.huji.ac.il> <16580.18293.951487.646134@xf11.fra.suse.de> <Pine.LNX.4.56.0406071439450.1130@gx-62.cs.huji.ac.il> <20040607130115.GV21062@fooishbar.org> <Pine.LNX.4.56.0406071718410.2123@gx-61.cs.huji.ac.il> Message-ID: <20040607142457.GW21062@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: agd5f@yahoo.com wrote on Monday, 7 June 2004 at 05:36:21 -0700 References: <16580.18293.951487.646134@xf11.fra.suse.de> <20040607123621.91705.qmail@web50104.mail.yahoo.com> Message-ID: <16580.34258.405410.800206@xf11.fra.suse.de> 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: <1086616171.31779.2.camel@support02.civic.twp.ypsilanti.mi.us> References: <20040607123621.91705.qmail@web50104.mail.yahoo.com> <1086616171.31779.2.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <Pine.LNX.4.56.0406071820390.21572@grok.cs.huji.ac.il> 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: <16580.34258.405410.800206@xf11.fra.suse.de> References: <16580.18293.951487.646134@xf11.fra.suse.de> <20040607123621.91705.qmail@web50104.mail.yahoo.com> <16580.34258.405410.800206@xf11.fra.suse.de> Message-ID: <Pine.LNX.4.56.0406071824250.21572@grok.cs.huji.ac.il> 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: <Pine.LNX.4.56.0406071820390.21572@grok.cs.huji.ac.il> References: <20040607123621.91705.qmail@web50104.mail.yahoo.com> <1086616171.31779.2.camel@support02.civic.twp.ypsilanti.mi.us> <Pine.LNX.4.56.0406071820390.21572@grok.cs.huji.ac.il> Message-ID: <1086622559.31779.21.camel@support02.civic.twp.ypsilanti.mi.us> 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 <elanthis@awesomeplay.com> AwesomePlay Productions, Inc. From mesacarlos at hotmail.com Mon Jun 7 08:59:10 2004 From: mesacarlos at hotmail.com (mesacarlos@hotmail.com) Date: Mon Jun 7 08:59:17 2004 Subject: [Xorg] Hello Message-ID: <mailman.31.1086623957.6724.xorg@freedesktop.org> 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: <mailman.465.1086624051.6725.xorg@freedesktop.org> Message-ID: <Pine.LNX.4.43.0406070921010.26162-100000@pilchuck.reedmedia.net> On Mon, 7 Jun 2004 xorg-request@freedesktop.org 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 slb5w@hotmail.com 1BVusv-0000tx-00 -- ZIP 2004-06-03 10:01:04 jpinfo@invitrogen.com 1BVvaR-0000wt-00 -- ZIP 2004-06-04 10:07:50 newsletter@zipzoomfly.com 1BWIAX-0002PH-00 -- ZIP 2004-06-03 12:50:44 xorg@freedesktop.org 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 (mcnichol@austin.ibm.com) Date: Mon Jun 7 11:01:43 2004 Subject: [Xorg] Dynamic mouse accelaration Message-ID: <200406071504.KAA33748@xanth.austin.ibm.com> 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 <daniel@freedesktop.org> > 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: <Pine.LNX.4.43.0406070921010.26162-100000@pilchuck.reedmedia.net> References: <Pine.LNX.4.43.0406070921010.26162-100000@pilchuck.reedmedia.net> Message-ID: <40C4D429.3030303@enthalpy.homelinux.org> Jeremy C. Reed wrote: >On Mon, 7 Jun 2004 xorg-request@freedesktop.org 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 slb5w@hotmail.com 1BVusv-0000tx-00 -- ZIP >2004-06-03 10:01:04 jpinfo@invitrogen.com 1BVvaR-0000wt-00 -- ZIP >2004-06-04 10:07:50 newsletter@zipzoomfly.com 1BWIAX-0002PH-00 -- ZIP >2004-06-03 12:50:44 xorg@freedesktop.org 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: <40C4D429.3030303@enthalpy.homelinux.org> References: <Pine.LNX.4.43.0406070921010.26162-100000@pilchuck.reedmedia.net> <40C4D429.3030303@enthalpy.homelinux.org> Message-ID: <40C4D826.70307@touchtunes.com> 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: <1086648427.30106.3.camel@d-mak.homelinux.org> 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." <1086648427.30106.3.camel@d-mak.homelinux.org> Message-ID: <E1BXTXR-0000RR-Bc@evo.keithp.com> 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: <16581.29655.431672.285482@xf11.fra.suse.de> 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: <16581.29655.431672.285482@xf11.fra.suse.de> Message-ID: <20040608125224.74741.qmail@web50109.mail.yahoo.com> --- Egbert Eich <eich@pdx.freedesktop.org> 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: <1086734051.25558.198032272@webmail.messagingengine.com> 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: <1086734051.25558.198032272@webmail.messagingengine.com> References: <1086734051.25558.198032272@webmail.messagingengine.com> Message-ID: <20040609093941.346461a5.glennm@hydrix.com> On Tue, 08 Jun 2004 15:34:11 -0700 "Asterius Pandoras" <asterius@airpost.net> 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: <40C6A14A.5030301@sun.com> 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- alan.coopersmith@sun.com 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: <40C6EF70.60502@cropdesign.com> 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 cropdesign@cropdesign.com 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 julius@solutions-i.org on Wed, Jun 09, 2004 at 01:42:02PM -0400 References: <1086802922.14427.5.camel@julius> Message-ID: <20040609214320.A28283@artificial-stupidity.net> 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: <20040609214320.A28283@artificial-stupidity.net> References: <1086802922.14427.5.camel@julius> <20040609214320.A28283@artificial-stupidity.net> 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: <1086780994.8194.5.camel@localhost.localdomain> 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: <1086780994.8194.5.camel@localhost.localdomain> References: <1086780994.8194.5.camel@localhost.localdomain> 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: <1086780994.8194.5.camel@localhost.localdomain> <1086792827.4192.62.camel@localhost> Message-ID: <1086791122.8203.26.camel@localhost.localdomain> 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: <200406091127.53716.hiryu@audioseek.net> 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: <200406091127.53716.hiryu@audioseek.net> References: <200406091127.53716.hiryu@audioseek.net> Message-ID: <Pine.LNX.4.60.0406091330480.6970@ozma.hauschen> 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 > xorg@freedesktop.org > 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: <40C763C1.5060705@xs4all.nl> 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: <E1BXTXR-0000RR-Bc@evo.keithp.com> References: <E1BXTXR-0000RR-Bc@evo.keithp.com> Message-ID: <1086817846.31461.0.camel@d-mak.homelinux.org> 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: <1086833443.8092.3.camel@vitorio.digitel.com.br> 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: <20040609230616.51890.qmail@web50102.mail.yahoo.com> --- Philip Van Hoof <spamfrommailing@freax.org> 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: <200406102304.56455.rafael.espindola@ic.unicamp.br> -----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: <200406102304.56455.rafael.espindola@ic.unicamp.br> References: <200406102304.56455.rafael.espindola@ic.unicamp.br> Message-ID: <40C969DD.2000205@sun.com> 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- alan.coopersmith@sun.com 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: <1086791122.8203.26.camel@localhost.localdomain> References: <1086780994.8194.5.camel@localhost.localdomain> <1086792827.4192.62.camel@localhost> <1086791122.8203.26.camel@localhost.localdomain> Message-ID: <1086974757.11936.6.camel@localhost.localdomain> > > 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <a728f9f904061208401b573b32@mail.gmail.com> On Sat, 12 Jun 2004 16:44:43 +0200, Michel D?nzer <michel@daenzer.net> 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: <a728f9f904061208401b573b32@mail.gmail.com> References: <1087021032.86211.53.camel@leguin> <1087051483.4193.169.camel@localhost> <a728f9f904061208401b573b32@mail.gmail.com> 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 <michel@daenzer.net> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <20040613020747.47417.qmail@web14921.mail.yahoo.com> 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 <eta@lclark.edu> 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 jonsmirl@yahoo.com __________________________________ 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: <200406111130.i5BBUYAH098892@www5.hotbox.ru> References: <200406111130.i5BBUYAH098892@www5.hotbox.ru> Message-ID: <40CBC116.8050707@sun.com> 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 xkb@listserv.bat.ru 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- alan.coopersmith@sun.com 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: <20040613020747.47417.qmail@web14921.mail.yahoo.com> References: <20040613020747.47417.qmail@web14921.mail.yahoo.com> 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 <eta@lclark.edu> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <20040613055524.5465.qmail@web14924.mail.yahoo.com> --- Eric Anholt <eta@lclark.edu> 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 jonsmirl@yahoo.com __________________________________ 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: <20040613020747.47417.qmail@web14921.mail.yahoo.com> 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: <200406131657.14572.kde@myrealbox.com> 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: <20040613020747.47417.qmail@web14921.mail.yahoo.com> References: <20040613020747.47417.qmail@web14921.mail.yahoo.com> Message-ID: <1087134781.2436.2.camel@localhost.localdomain> 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: <20040613151907.87558.qmail@web14927.mail.yahoo.com> --- Martijn Sipkema <msipkema@sipkema-digital.com> 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 jonsmirl@yahoo.com __________________________________ 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: <1087134781.2436.2.camel@localhost.localdomain> Message-ID: <20040613153446.43044.qmail@web14930.mail.yahoo.com> --- Alan Cox <alan@lxorguk.ukuu.org.uk> 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 jonsmirl@yahoo.com __________________________________ 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: <20040613153446.43044.qmail@web14930.mail.yahoo.com> References: <20040613153446.43044.qmail@web14930.mail.yahoo.com> Message-ID: <40CC8012.1030700@sun.com> Jon Smirl wrote: > --- Alan Cox <alan@lxorguk.ukuu.org.uk> 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- alan.coopersmith@sun.com 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: <20040613153446.43044.qmail@web14930.mail.yahoo.com> <40CC8012.1030700@sun.com> Message-ID: <40CC8ED5.94A3A3D5@nrubsig.org> 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <200406131937.03736.braun@club-internet.fr> 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: <20040613153446.43044.qmail@web14930.mail.yahoo.com> References: <20040613153446.43044.qmail@web14930.mail.yahoo.com> Message-ID: <1087144961.3191.4.camel@localhost.localdomain> 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: <1087144961.3191.4.camel@localhost.localdomain> Message-ID: <20040613191343.55526.qmail@web14923.mail.yahoo.com> --- Alan Cox <alan@lxorguk.ukuu.org.uk> 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 jonsmirl@yahoo.com __________________________________ 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: <1087144961.3191.4.camel@localhost.localdomain> References: <20040613153446.43044.qmail@web14930.mail.yahoo.com> <1087144961.3191.4.camel@localhost.localdomain> Message-ID: <40CCA916.6060605@pobox.com> 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: <Pine.LNX.4.56.0406131940430.14454@grok.cs.huji.ac.il> Message-ID: <20040613192516.5319.qmail@web14924.mail.yahoo.com> --- Ely Levy <elylevy@cs.huji.ac.il> 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 jonsmirl@yahoo.com __________________________________ 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: <40CC8012.1030700@sun.com> Message-ID: <20040613193520.53242.qmail@web14922.mail.yahoo.com> --- Alan Coopersmith <Alan.Coopersmith@Sun.COM> 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 jonsmirl@yahoo.com __________________________________ 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: <20040613193520.53242.qmail@web14922.mail.yahoo.com> References: <20040613193520.53242.qmail@web14922.mail.yahoo.com> Message-ID: <1087153033.3256.7.camel@localhost.localdomain> 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: <EKENLNBIDBAHKIELDLPNEEBDCDAA.matt@genesi.co.uk> References: <EKENLNBIDBAHKIELDLPNEEBDCDAA.matt@genesi.co.uk> Message-ID: <1087153448.3255.15.camel@localhost.localdomain> 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: <40CCA916.6060605@pobox.com> References: <20040613153446.43044.qmail@web14930.mail.yahoo.com> <1087144961.3191.4.camel@localhost.localdomain> <40CCA916.6060605@pobox.com> Message-ID: <1087153643.3255.19.camel@localhost.localdomain> 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: <1087153448.3255.15.camel@localhost.localdomain> Message-ID: <20040613210354.88808.qmail@web14930.mail.yahoo.com> --- Alan Cox <alan@lxorguk.ukuu.org.uk> 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 jonsmirl@yahoo.com __________________________________ 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: <1087153643.3255.19.camel@localhost.localdomain> Message-ID: <20040613211151.51375.qmail@web14926.mail.yahoo.com> --- Alan Cox <alan@lxorguk.ukuu.org.uk> 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 jonsmirl@yahoo.com __________________________________ 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: <EKENLNBIDBAHKIELDLPNEEBDCDAA.matt@genesi.co.uk> Message-ID: <20040613212902.59148.qmail@web14929.mail.yahoo.com> --- Matt Sealey <matt@genesi.co.uk> 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 jonsmirl@yahoo.com __________________________________ 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: <NCBBKNKBDJMACOBOLDMKAEMEGFAA.jdennis@redhat.com> Message-ID: <20040613214131.41142.qmail@web14927.mail.yahoo.com> --- John Dennis <jdennis@redhat.com> 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 jonsmirl@yahoo.com __________________________________ 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: <20040613193520.53242.qmail@web14922.mail.yahoo.com> References: <20040613193520.53242.qmail@web14922.mail.yahoo.com> 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: <20040613214131.41142.qmail@web14927.mail.yahoo.com> References: <20040613214131.41142.qmail@web14927.mail.yahoo.com> Message-ID: <1087160902.3255.60.camel@localhost.localdomain> 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: <20040613215814.98934.qmail@web11903.mail.yahoo.com> References: <20040613215814.98934.qmail@web11903.mail.yahoo.com> Message-ID: <1087161135.3239.64.camel@localhost.localdomain> 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: <E1BZfEu-0000Us-0X@evo.keithp.com> 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." <1087153448.3255.15.camel@localhost.localdomain> Message-ID: <E1BZfVI-0000ZG-J3@evo.keithp.com> 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: <20040613191343.55526.qmail@web14923.mail.yahoo.com> References: <1087144961.3191.4.camel@localhost.localdomain> <20040613191343.55526.qmail@web14923.mail.yahoo.com> Message-ID: <20040614035747.GD15322@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040614035747.GD15322@fooishbar.org> Message-ID: <20040614050759.11407.qmail@web14928.mail.yahoo.com> X on GL has no impact on remote X. Tests with glitz show a 100:1 speed improvement for local drawing. --- Daniel Stone <daniel@freedesktop.org> 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 > <daniel@freedesktop.org> > freedesktop.org: powering your desktop > http://www.freedesktop.org > > ATTACHMENT part 2 application/pgp-signature name=signature.asc ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <20040614050759.11407.qmail@web14928.mail.yahoo.com> References: <20040614035747.GD15322@fooishbar.org> <20040614050759.11407.qmail@web14928.mail.yahoo.com> Message-ID: <20040614052038.GG15322@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040614052038.GG15322@fooishbar.org> Message-ID: <20040614054258.56352.qmail@web14930.mail.yahoo.com> 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 <daniel@freedesktop.org> 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 > <daniel@freedesktop.org> > freedesktop.org: powering your desktop > http://www.freedesktop.org > > ATTACHMENT part 2 application/pgp-signature name=signature.asc ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <20040614054258.56352.qmail@web14930.mail.yahoo.com> References: <20040614052038.GG15322@fooishbar.org> <20040614054258.56352.qmail@web14930.mail.yahoo.com> Message-ID: <20040614055144.GH15322@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040614055144.GH15322@fooishbar.org> Message-ID: <20040614064406.42315.qmail@web14922.mail.yahoo.com> --- Daniel Stone <daniel@freedesktop.org> 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 > <daniel@freedesktop.org> > freedesktop.org: powering your desktop > http://www.freedesktop.org > > ATTACHMENT part 2 application/pgp-signature name=signature.asc ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <20040614064406.42315.qmail@web14922.mail.yahoo.com> References: <20040614055144.GH15322@fooishbar.org> <20040614064406.42315.qmail@web14922.mail.yahoo.com> Message-ID: <20040614065121.GI15322@fooishbar.org> On Sun, Jun 13, 2004 at 11:44:06PM -0700, Jon Smirl wrote: > --- Daniel Stone <daniel@freedesktop.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040614064406.42315.qmail@web14922.mail.yahoo.com> <Pine.LNX.4.58.0406140751140.14086@skynet> Message-ID: <20040614071952.GK15322@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: eta@lclark.edu wrote on Friday, 11 June 2004 at 23:15:22 -0700 References: <1087020922.86211.49.camel@leguin> Message-ID: <16589.29543.606104.301759@xf11.fra.suse.de> 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: <40CD7797.5010405@tungstengraphics.com> 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: <16589.29543.606104.301759@xf11.fra.suse.de> References: <1087020922.86211.49.camel@leguin> <16589.29543.606104.301759@xf11.fra.suse.de> Message-ID: <20040614100622.GL15322@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <200406141213.25700.grifis87@virgilio.it> 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: <200406131657.14572.kde@myrealbox.com> References: <200406131657.14572.kde@myrealbox.com> Message-ID: <200406140820.12576.rafael.espindola@ic.unicamp.br> -----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 (xkb@listserv.bat.ru) 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." <16589.29543.606104.301759@xf11.fra.suse.de> Message-ID: <E1BZuSL-0005Mx-IZ@evo.keithp.com> 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." <EKENLNBIDBAHKIELDLPNKEBECDAA.matt@genesi.co.uk> Message-ID: <E1BZuGk-0005Lf-OG@evo.keithp.com> 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: <200406142032.55484.p.postmus@st.hanze.nl> 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." <Pine.LNX.4.56.0406141952470.17573@grok.cs.huji.ac.il> Message-ID: <E1BZwKL-0005QQ-Hn@evo.keithp.com> 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: <200406142032.55484.p.postmus@st.hanze.nl> References: <200406142032.55484.p.postmus@st.hanze.nl> Message-ID: <20040614184032.GB1058@fooishbar.org> 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 <daniel@freedesktop.org> 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 (mcnichol@austin.ibm.com) Date: Mon Jun 14 12:32:38 2004 Subject: [Xorg] VFB in fd.o xserver. Message-ID: <200406141932.OAA27618@xanth.austin.ibm.com> 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: <200406142032.55484.p.postmus@st.hanze.nl> Message-ID: <Pine.LNX.4.43.0406141245030.26162-100000@pilchuck.reedmedia.net> 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: <E1BZwKL-0005QQ-Hn@evo.keithp.com> Message-ID: <Pine.LNX.4.43.0406141250290.26162-100000@pilchuck.reedmedia.net> 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: <200406141932.OAA27618@xanth.austin.ibm.com> Message-ID: <40CE04C4.3030305@sun.com> There is "dummy_drv.o" which provides the needed function. skk mcnichol@austin.ibm.com 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 >xorg@freedesktop.org >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: <Pine.LNX.4.43.0406141245030.26162-100000@pilchuck.reedmedia.net> References: <Pine.LNX.4.43.0406141245030.26162-100000@pilchuck.reedmedia.net> Message-ID: <1087243410.4227.49.camel@shaman.txp> 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." <200406141932.OAA27618@xanth.austin.ibm.com> Message-ID: <E1BZxuo-0005UH-Oz@evo.keithp.com> Around 14 o'clock on Jun 14, mcnichol@austin.ibm.com 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: <200406142032.55484.p.postmus@st.hanze.nl> References: <200406142032.55484.p.postmus@st.hanze.nl> Message-ID: <a728f9f9040614134499bd864@mail.gmail.com> On Mon, 14 Jun 2004 20:32:55 +0200, Peter Postmus <p.postmus@st.hanze.nl> 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: <E1BZuSL-0005Mx-IZ@evo.keithp.com> References: <E1BZuSL-0005Mx-IZ@evo.keithp.com> Message-ID: <1087242489.5999.11.camel@localhost.localdomain> 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: <1087242489.5999.11.camel@localhost.localdomain> References: <E1BZuSL-0005Mx-IZ@evo.keithp.com> <1087242489.5999.11.camel@localhost.localdomain> Message-ID: <40CE1182.5060806@eutonian.com> 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 (mcnichol@austin.ibm.com) Date: Mon Jun 14 14:12:06 2004 Subject: [Xorg] VFB in fd.o xserver. Message-ID: <200406142111.QAA32946@xanth.austin.ibm.com> Thanks Keith. Any idea which branch that might be in? I don't see it in the head branch. Dan > From keithp@keithp.com Mon Jun 14 15:19:14 2004 > > > Around 14 o'clock on Jun 14, mcnichol@austin.ibm.com 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: <40CE1182.5060806@eutonian.com> Message-ID: <Pine.LNX.4.43.0406141415160.26162-100000@pilchuck.reedmedia.net> 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: <a728f9f9040614134499bd864@mail.gmail.com> Message-ID: <20040614215658.15601.qmail@web14930.mail.yahoo.com> --- Alex Deucher <alexdeucher@gmail.com> 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 jonsmirl@yahoo.com __________________________________ 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: <Pine.LNX.4.43.0406141415160.26162-100000@pilchuck.reedmedia.net> References: <Pine.LNX.4.43.0406141415160.26162-100000@pilchuck.reedmedia.net> Message-ID: <40CE2006.60209@eutonian.com> 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." <1087242489.5999.11.camel@localhost.localdomain> Message-ID: <E1BZzY7-0005Vw-11@evo.keithp.com> 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." <200406142111.QAA32946@xanth.austin.ibm.com> Message-ID: <E1BZzau-0005Wf-MC@evo.keithp.com> Around 16 o'clock on Jun 14, mcnichol@austin.ibm.com 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: <200406142243.i5EMh4413448@magic.shiman.com> References: <200406142243.i5EMh4413448@magic.shiman.com> Message-ID: <40CE3556.8020508@eutonian.com> 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: <40CE3556.8020508@eutonian.com> References: <200406142243.i5EMh4413448@magic.shiman.com> <40CE3556.8020508@eutonian.com> Message-ID: <E1Ba2F1-0006N4-00@brudder.east.isi.edu> 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: <E1BZzY7-0005Vw-11@evo.keithp.com> References: <E1BZzY7-0005Vw-11@evo.keithp.com> Message-ID: <E1Ba2y1-0006PX-00@brudder.east.isi.edu> 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: <E1Ba2y1-0006PX-00@brudder.east.isi.edu> References: <E1BZzY7-0005Vw-11@evo.keithp.com> <E1Ba2y1-0006PX-00@brudder.east.isi.edu> Message-ID: <1087264678.3398.1.camel@stargrazer.home.awesomeplay.com> 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 > xorg@freedesktop.org > 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: <E1BZwKL-0005QQ-Hn@evo.keithp.com> References: <E1BZwKL-0005QQ-Hn@evo.keithp.com> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <E1BZzY7-0005Vw-11@evo.keithp.com> References: <1087242489.5999.11.camel@localhost.localdomain> <E1BZzY7-0005Vw-11@evo.keithp.com> Message-ID: <20040615031535.GF1058@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <E1Ba2y1-0006PX-00@brudder.east.isi.edu> References: <E1BZzY7-0005Vw-11@evo.keithp.com> <E1Ba2y1-0006PX-00@brudder.east.isi.edu> Message-ID: <20040615031627.GG1058@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <Pine.LNX.4.43.0406141250290.26162-100000@pilchuck.reedmedia.net> References: <E1BZwKL-0005QQ-Hn@evo.keithp.com> <Pine.LNX.4.43.0406141250290.26162-100000@pilchuck.reedmedia.net> Message-ID: <20040615031745.GH1058@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040615040011.38821.qmail@web11906.mail.yahoo.com> References: <20040615040011.38821.qmail@web11906.mail.yahoo.com> Message-ID: <1087302976.6040.14.camel@localhost.localdomain> > 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: <E1BZzY7-0005Vw-11@evo.keithp.com> References: <E1BZzY7-0005Vw-11@evo.keithp.com> Message-ID: <1087303536.6040.21.camel@localhost.localdomain> 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: keithp@keithp.com wrote on Monday, 14 June 2004 at 09:37:09 -0700 References: <16589.29543.606104.301759@xf11.fra.suse.de> <E1BZuSL-0005Mx-IZ@evo.keithp.com> Message-ID: <16591.13147.890751.844637@xf11.fra.suse.de> 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: <16591.13147.890751.844637@xf11.fra.suse.de> References: <16589.29543.606104.301759@xf11.fra.suse.de> <E1BZuSL-0005Mx- IZ@evo.keithp.com> <16591.13147.890751.844637@xf11.fra.suse.de> Message-ID: <40CF3EC6.7010003@tungstengraphics.com> 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: <1087352536.9878.198508876@webmail.messagingengine.com> 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: <1087352536.9878.198508876@webmail.messagingengine.com> References: <1087352536.9878.198508876@webmail.messagingengine.com> Message-ID: <48205.205.241.48.33.1087353377.squirrel@spidermail.richmond.edu> 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: <1087352536.9878.198508876@webmail.messagingengine.com>; from asterius@airpost.net on Tue, Jun 15, 2004 at 06:22:16PM -0800 References: <1087352536.9878.198508876@webmail.messagingengine.com> Message-ID: <20040616123647.A60251@artificial-stupidity.net> 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 > xorg@freedesktop.org > 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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 eta@lclark.edu. 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <a728f9f90406160559239a8f20@mail.gmail.com> On Wed, 16 Jun 2004 03:43:22 -0700, Eric Anholt <eta@lclark.edu> 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 eta@lclark.edu. 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 eta@lclark.edu > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > 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: <Pine.LNX.4.56.0406161726200.14517@gx-78.cs.huji.ac.il> 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 eta@lclark.edu. 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 eta@lclark.edu > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > > > > _______________________________________________ > xorg mailing list > xorg@freedesktop.org > 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: <40D05E51.254D71AD@nrubsig.org> 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 eta@lclark.edu. 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <C6689B70-BFA6-11D8-852F-00039390D626@pepper.com> 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: <1087405900.32633.39.camel@mightymax.charlietech.com> 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 <charlie@vexi.org> 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: <1087406067.22875.21.camel@support02.civic.twp.ypsilanti.mi.us> References: <1087405900.32633.39.camel@mightymax.charlietech.com> <1087406067.22875.21.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1087407744.32633.48.camel@mightymax.charlietech.com> 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 <charlie@vexi.org> 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: <a728f9f90406160559239a8f20@mail.gmail.com> References: <1087382601.94770.14.camel@leguin> <a728f9f90406160559239a8f20@mail.gmail.com> 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 <eta@lclark.edu> 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 eta@lclark.edu. 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <200406161202.47828.hiryu@audioseek.net> 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: <Pine.LNX.4.56.0406161726200.14517@gx-78.cs.huji.ac.il> References: <Pine.LNX.4.56.0406161726200.14517@gx-78.cs.huji.ac.il> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <40D05E51.254D71AD@nrubsig.org> References: <1087382601.94770.14.camel@leguin> <40D05E51.254D71AD@nrubsig.org> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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> <40D05E51.254D71AD@nrubsig.org> 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" <roland.mainz@nrubsig.org> To: "Eric Anholt" <eta@lclark.edu> Cc: <xorg@freedesktop.org> 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 eta@lclark.edu. 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) roland.mainz@nrubsig.org > \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer > /O /==\ O\ TEL +49 641 7950090 > (;O/ \/ \O;) > > _______________________________________________ > xorg mailing list > xorg@freedesktop.org > 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: <200406161202.47828.hiryu@audioseek.net> References: <200406161202.47828.hiryu@audioseek.net> Message-ID: <200406162159.13350.braun@club-internet.fr> 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: <200406162159.13350.braun@club-internet.fr> References: <200406161202.47828.hiryu@audioseek.net> <200406162159.13350.braun@club-internet.fr> Message-ID: <200406162342.13812.braun@club-internet.fr> 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: <200406162342.13812.braun@club-internet.fr> References: <200406161202.47828.hiryu@audioseek.net> <200406162159.13350.braun@club-internet.fr> <200406162342.13812.braun@club-internet.fr> Message-ID: <200406161526.53596.hiryu@audioseek.net> 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 > xorg@freedesktop.org > 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: <C6689B70-BFA6-11D8-852F-00039390D626@pepper.com> References: <C6689B70-BFA6-11D8-852F-00039390D626@pepper.com> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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> <40D05E51.254D71AD@nrubsig.org> <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: <1087434603.30641.198588273@webmail.messagingengine.com> 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. mz@artificial-stupidity.net> 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 > > xorg@freedesktop.org > > 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: <1087405900.32633.39.camel@mightymax.charlietech.com> References: <1087405900.32633.39.camel@mightymax.charlietech.com> Message-ID: <20040617031508.GI19106@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <1087407744.32633.48.camel@mightymax.charlietech.com> References: <1087405900.32633.39.camel@mightymax.charlietech.com> <1087406067.22875.21.camel@support02.civic.twp.ypsilanti.mi.us> <1087407744.32633.48.camel@mightymax.charlietech.com> Message-ID: <20040617031739.GJ19106@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040617031739.GJ19106@fooishbar.org> Message-ID: <20040617035503.59175.qmail@web14926.mail.yahoo.com> 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 <daniel@freedesktop.org> 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 > <daniel@freedesktop.org> > freedesktop.org: powering your desktop > http://www.freedesktop.org > > ATTACHMENT part 1.2 application/pgp-signature name=signature.asc > _______________________________________________ > xorg mailing list > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg > ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <20040617035503.59175.qmail@web14926.mail.yahoo.com> References: <20040617031739.GJ19106@fooishbar.org> <20040617035503.59175.qmail@web14926.mail.yahoo.com> Message-ID: <20040617042654.GM19106@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <593815875.20040617082532@freemail.hu> 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:dev.macs@freemail.hu 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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> <40D05E51.254D71AD@nrubsig.org><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: <40D175BA.7010108@winischhofer.net> 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: <40D188B2.2060905@winischhofer.net> 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 (stratos@zeelandnet.nl) Date: Thu Jun 17 05:38:52 2004 Subject: [Xorg] xserver undefined symbol: BuiltinRegisterFpefunctions Message-ID: <44466.127.0.0.1.1087475900.squirrel@secure.zeelandnet.nl> 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: <593815875.20040617082532@freemail.hu> References: <593815875.20040617082532@freemail.hu> Message-ID: <a728f9f9040617055821405b69@mail.gmail.com> On Thu, 17 Jun 2004 08:25:32 +0200, Dev.Macs <dev.macs@freemail.hu> 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:dev.macs@freemail.hu > 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: <a728f9f904061706014881a118@mail.gmail.com> On Thu, 17 Jun 2004 03:00:15 -0700, Eric Anholt <eta@lclark.edu> 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 eta@lclark.edu > http://people.freebsd.org/~anholt/ anholt@FreeBSD.org > 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: <40D188B2.2060905@winischhofer.net> References: <40D188B2.2060905@winischhofer.net> Message-ID: <40D1B40F.6060402@tungstengraphics.com> 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 / \/\ _ jens@tungstengraphics.com / \ \ \ 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: <40D1B40F.6060402@tungstengraphics.com> References: <40D188B2.2060905@winischhofer.net> <40D1B40F.6060402@tungstengraphics.com> Message-ID: <40D1CB16.3010305@winischhofer.net> 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: <44466.127.0.0.1.1087475900.squirrel@secure.zeelandnet.nl> References: <44466.127.0.0.1.1087475900.squirrel@secure.zeelandnet.nl> Message-ID: <200406171025.42727.hiryu@audioseek.net> 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, stratos@zeelandnet.nl 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 > xorg@freedesktop.org > 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: <40D1CB16.3010305@winischhofer.net> References: <40D188B2.2060905@winischhofer.net> <40D1B40F.6060402@tungstengraphics.com> <40D1CB16.3010305@winischhofer.net> Message-ID: <40D1D441.4080308@tungstengraphics.com> 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 / \/\ _ jens@tungstengraphics.com / \ \ \ 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." <44466.127.0.0.1.1087475900.squirrel@secure.zeelandnet.nl> Message-ID: <E1Bb0j9-00014d-46@evo.keithp.com> > ./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: <40D1D441.4080308@tungstengraphics.com> References: <40D188B2.2060905@winischhofer.net> <40D1B40F.6060402@tungstengraphics.com> <40D1CB16.3010305@winischhofer.net> <40D1D441.4080308@tungstengraphics.com> Message-ID: <40D1D638.8030606@winischhofer.net> 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: <40D1D441.4080308@tungstengraphics.com> References: <40D188B2.2060905@winischhofer.net> <40D1B40F.6060402@tungstengraphics.com> <40D1CB16.3010305@winischhofer.net> <40D1D441.4080308@tungstengraphics.com> Message-ID: <40D1DC41.3050908@sun.com> 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- alan.coopersmith@sun.com 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: <200405241453.IAA15954@anderson.fc.hp.com> 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: <1087511254.28382.198661593@webmail.messagingengine.com> 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: <a728f9f904061706014881a118@mail.gmail.com> References: <1087466415.7506.6.camel@leguin> <a728f9f904061706014881a118@mail.gmail.com> 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 <eta@lclark.edu> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <40D2633B.FB3F6E93@nrubsig.org> 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <40D2633B.FB3F6E93@nrubsig.org> References: <40D2633B.FB3F6E93@nrubsig.org> Message-ID: <20040618034334.GC3565@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040618035230.13985.qmail@web14927.mail.yahoo.com> 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 jonsmirl@yahoo.com __________________________________ 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: <20040618035230.13985.qmail@web14927.mail.yahoo.com> References: <20040618035230.13985.qmail@web14927.mail.yahoo.com> Message-ID: <20040618035403.GD3565@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040618035403.GD3565@fooishbar.org> Message-ID: <20040618040439.17385.qmail@web14921.mail.yahoo.com> --- Daniel Stone <daniel@freedesktop.org> 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 jonsmirl@yahoo.com __________________________________ 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: <20040618040439.17385.qmail@web14921.mail.yahoo.com> References: <20040618035403.GD3565@fooishbar.org> <20040618040439.17385.qmail@web14921.mail.yahoo.com> Message-ID: <20040618042027.GE3565@fooishbar.org> On Thu, Jun 17, 2004 at 09:04:39PM -0700, Jon Smirl wrote: > --- Daniel Stone <daniel@freedesktop.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40D2633B.FB3F6E93@nrubsig.org> <20040618034334.GC3565@fooishbar.org> Message-ID: <40D27496.F4E4CD37@nrubsig.org> 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <40D27496.F4E4CD37@nrubsig.org> References: <40D2633B.FB3F6E93@nrubsig.org> <20040618034334.GC3565@fooishbar.org> <40D27496.F4E4CD37@nrubsig.org> Message-ID: <20040618045930.GF3565@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040618035403.GD3565@fooishbar.org> 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: <20040618035403.GD3565@fooishbar.org> <Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il> Message-ID: <20040618091333.GG3565@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040618040439.17385.qmail@web14921.mail.yahoo.com> References: <20040618040439.17385.qmail@web14921.mail.yahoo.com> Message-ID: <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> 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: <20040618091333.GG3565@fooishbar.org> References: <20040618035403.GD3565@fooishbar.org> <Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il> <20040618091333.GG3565@fooishbar.org> Message-ID: <Pine.LNX.4.58.0406181533080.5906@ask.diku.dk> 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: <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> References: <20040618040439.17385.qmail@web14921.mail.yahoo.com> <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> Message-ID: <40D3115B.7070203@sun.com> 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- alan.coopersmith@sun.com 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: <Pine.LNX.4.56.0406181904060.31709@grok.cs.huji.ac.il> > 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: <40D3115B.7070203@sun.com> Message-ID: <20040618161732.29270.qmail@web14926.mail.yahoo.com> 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 <Alan.Coopersmith@Sun.COM> 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- alan.coopersmith@sun.com > Sun Microsystems, Inc. - X Window System Engineering > > > _______________________________________________ > xorg mailing list > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg > ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <40D3115B.7070203@sun.com> References: <20040618040439.17385.qmail@web14921.mail.yahoo.com> <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> <40D3115B.7070203@sun.com> Message-ID: <1087577957.27081.3.camel@mightymax.charlietech.com> 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 <charlie@vexi.org> 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: <40D3115B.7070203@sun.com> References: <20040618040439.17385.qmail@web14921.mail.yahoo.com> <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> <40D3115B.7070203@sun.com> Message-ID: <1087579123.16449.32.camel@support02.civic.twp.ypsilanti.mi.us> 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 <elanthis@awesomeplay.com> 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: <40D35EA8.8010103@winischhofer.net> 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: <1087579123.16449.32.camel@support02.civic.twp.ypsilanti.mi.us> References: <20040618040439.17385.qmail@web14921.mail.yahoo.com> <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> <40D3115B.7070203@sun.com> <1087579123.16449.32.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1087594843.27081.6.camel@mightymax.charlietech.com> 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 <charlie@vexi.org> 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: <40D35EA8.8010103@winischhofer.net> References: <40D35EA8.8010103@winischhofer.net> Message-ID: <40D367EA.6050405@Sun.COM> 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- alan.coopersmith@sun.com 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: <200405241453.IAA15954@anderson.fc.hp.com> 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 > xorg@freedesktop.org > 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: <200405241453.IAA15954@anderson.fc.hp.com> <40D31540.22608.32F798A1@localhost> Message-ID: <1087605084.27081.10.camel@mightymax.charlietech.com> 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 <charlie@vexi.org> 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: <1087605084.27081.10.camel@mightymax.charlietech.com> References: <40D31540.22608.32F798A1@localhost> Message-ID: <40D33227.18712.336880BE@localhost> Charles Goodwin <charlie@vexi.org> 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: <40D2633B.FB3F6E93@nrubsig.org> <20040618034334.GC3565@fooishbar.org> <40D27496.F4E4CD37@nrubsig.org> <20040618045930.GF3565@fooishbar.org> Message-ID: <40D39910.7F06DB7F@nrubsig.org> 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <40D3A8A1.6020705@Sun.COM> 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- alan.coopersmith@sun.com 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: <40D39910.7F06DB7F@nrubsig.org> References: <40D2633B.FB3F6E93@nrubsig.org> <20040618034334.GC3565@fooishbar.org> <40D27496.F4E4CD37@nrubsig.org> <20040618045930.GF3565@fooishbar.org> <40D39910.7F06DB7F@nrubsig.org> Message-ID: <1087614319.15616.1.camel@mightymax.charlietech.com> 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 <charlie@vexi.org> 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: <E1BbXJb-0007oP-F5@evo.keithp.com> 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: <E1BbXOI-0007pZ-5E@evo.keithp.com> 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: <40D3115B.7070203@sun.com> References: <20040618040439.17385.qmail@web14921.mail.yahoo.com> <Pine.LNX.4.56.0406181347150.23379@grok.cs.huji.ac.il> <40D3115B.7070203@sun.com> Message-ID: <5b18a542040619135316044d21@mail.gmail.com> On Fri, 18 Jun 2004 08:59:23 -0700, Alan Coopersmith <alan.coopersmith@sun.com> 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- alan.coopersmith@sun.com > Sun Microsystems, Inc. - X Window System Engineering > > > > > _______________________________________________ > xorg mailing list > xorg@freedesktop.org > 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: <40D27496.F4E4CD37@nrubsig.org> References: <40D2633B.FB3F6E93@nrubsig.org> <20040618034334.GC3565@fooishbar.org> <40D27496.F4E4CD37@nrubsig.org> Message-ID: <1087678670.26574.19.camel@localhost.localdomain> 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: <E1Bb0j9-00014d-46@evo.keithp.com> References: <E1Bb0j9-00014d-46@evo.keithp.com> Message-ID: <1087678770.26574.21.camel@localhost.localdomain> 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." <1087678770.26574.21.camel@localhost.localdomain> Message-ID: <E1Bbo1j-0002qK-HK@evo.keithp.com> 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: <1087695284.24155.198776219@webmail.messagingengine.com> 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: <20040618091333.GG3565@fooishbar.org> References: <20040618035403.GD3565@fooishbar.org> <Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il> <20040618091333.GG3565@fooishbar.org> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org -------------- 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: <20040620103823.GA19499@markh.linuxfromscratch.org> 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
## 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: <20040620191714.1a1b820e.spyro@f2s.com> References: <40D188B2.2060905@winischhofer.net> <40D1B40F.6060402@tungstengraphics.com> <40D1CB16.3010305@winischhofer.net> <40D1D441.4080308@tungstengraphics.com> <40D1DC41.3050908@sun.com> <20040620191714.1a1b820e.spyro@f2s.com> 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 <Alan.Coopersmith@Sun.COM> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <40D188B2.2060905@winischhofer.net> <40D1B40F.6060402@tungstengraphics.com> <40D1CB16.3010305@winischhofer.net> <40D1D441.4080308@tungstengraphics.com> <40D1DC41.3050908@sun.com> <20040620191714.1a1b820e.spyro@f2s.com> <1087756076.887.1.camel@leguin> Message-ID: <20040620184012.GU3565@fooishbar.org> 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 <Alan.Coopersmith@Sun.COM> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40D6E682.2040701@tungstengraphics.com> -------------- next part -------------- An embedded message was scrubbed... From: Keith Whitwell <keith@tungstengraphics.com> 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: <40D6E682.2040701@tungstengraphics.com> References: <40D6E682.2040701@tungstengraphics.com> Message-ID: <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> Message-ID: <40D6F4AA.1090208@tungstengraphics.com> 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: <40D6F4AA.1090208@tungstengraphics.com> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> Message-ID: <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <40D6FDE6.1060406@yahoo.com> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> <40D6FDE6.1060406@yahoo.com> Message-ID: <40D700BF.20800@tungstengraphics.com> 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: <40D700BF.20800@tungstengraphics.com> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> <40D6FDE6.1060406@yahoo.com> <40D700BF.20800@tungstengraphics.com> Message-ID: <Pine.LNX.4.58.0406211740250.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <40D70570.4010606@yahoo.com> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> <40D6FDE6.1060406@yahoo.com> <40D700BF.20800@tungstengraphics.com> <Pine.LNX.4.58.0406211740250.18487@odoaker.hrz.tu-chemnitz.de> <40D70570.4010606@yahoo.com> Message-ID: <Pine.LNX.4.58.0406211758080.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <40D6F4AA.1090208@tungstengraphics.com> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> 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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <BAY2-F149RcE5c439R900079635@hotmail.com> 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: <E1BbXOI-0007pZ-5E@evo.keithp.com> References: Your message of "Fri, 18 Jun 2004 18:19:19 PDT." <40D33227.18712.336880BE@localhost> Message-ID: <40D7029F.17529.424ED38A@localhost> Keith Packard <keithp@keithp.com> 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: <200406212334.i5LNYHjR011044@hal.plugon.com.br> 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: <1087864133.30613.198897723@webmail.messagingengine.com> 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: <1087864133.30613.198897723@webmail.messagingengine.com> References: <1087864133.30613.198897723@webmail.messagingengine.com> Message-ID: <20040622004521.GA4193@aus.sun.com> 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 <asterius@airpost.net> > To: xorg@freedesktop.org > 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 > xorg@freedesktop.org > 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: <9930.1087897079@www14.gmx.net> 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: <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> Message-ID: <40D86AAD.8040901@tungstengraphics.com> 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: <a728f9f90406221039521c104e@mail.gmail.com> On Tue, 22 Jun 2004 11:21:40 -0600, Mark Cuss <mcuss@cdlsystems.com> 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: <a728f9f90406221039521c104e@mail.gmail.com> Message-ID: <20040622182046.87162.qmail@web14921.mail.yahoo.com> 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 <alexdeucher@gmail.com> wrote: > On Tue, 22 Jun 2004 11:21:40 -0600, Mark Cuss <mcuss@cdlsystems.com> > 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 > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg > ===== Jon Smirl jonsmirl@yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail From 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: <1087864133.30613.198897723@webmail.messagingengine.com> References: <1087864133.30613.198897723@webmail.messagingengine.com> Message-ID: <40D89709.7040909@telia.com> 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 > xorg@freedesktop.org > 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: <20040622182046.87162.qmail@web14921.mail.yahoo.com> 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" <jonsmirl@yahoo.com> To: "Alex Deucher" <alexdeucher@gmail.com>; <mcuss@cdlsystems.com> Cc: <xorg@freedesktop.org> 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 <alexdeucher@gmail.com> wrote: > > On Tue, 22 Jun 2004 11:21:40 -0600, Mark Cuss <mcuss@cdlsystems.com> > > 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 > > xorg@freedesktop.org > > http://freedesktop.org/mailman/listinfo/xorg > > > > > ===== > Jon Smirl > jonsmirl@yahoo.com > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > From 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: <40D86AAD.8040901@tungstengraphics.com> References: <40D6E682.2040701@tungstengraphics.com> <Pine.LNX.4.58.0406211557040.18487@odoaker.hrz.tu-chemnitz.de> <40D6F4AA.1090208@tungstengraphics.com> <Pine.LNX.4.58.0406211650420.18487@odoaker.hrz.tu-chemnitz.de> <40D86AAD.8040901@tungstengraphics.com> Message-ID: <Pine.LNX.4.58.0406222102580.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <20040622192437.GA4867@markh.linuxfromscratch.org> 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: <20040622192548.GB4867@markh.linuxfromscratch.org> 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
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: <20040622192652.GC4867@markh.linuxfromscratch.org> 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])
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: <20040622182046.87162.qmail@web14921.mail.yahoo.com> References: <20040622182046.87162.qmail@web14921.mail.yahoo.com> Message-ID: <40D8D0B9.1040303@winischhofer.net> [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: <20040622183217.82403.qmail@web14929.mail.yahoo.com> References: <20040622183217.82403.qmail@web14929.mail.yahoo.com> Message-ID: <40D8D1B9.3090101@winischhofer.net> Jon Smirl wrote: > --- Thomas Winischhofer <thomas@winischhofer.net> 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: <1087957146.30891.198984005@webmail.messagingengine.com> 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: <1088004325.27145.44.camel@circle.hypercube> 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: <20040623155324.GB7497@kem.org> 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: <20040623155324.GB7497@kem.org> References: <20040623155324.GB7497@kem.org> Message-ID: <40D9AA53.6030103@tungstengraphics.com> 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: <40D9AA53.6030103@tungstengraphics.com> References: <20040623155324.GB7497@kem.org> <40D9AA53.6030103@tungstengraphics.com> Message-ID: <20040623173334.GB8407@kem.org> 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: <40D9BFAE.8060801@bitplanet.net> 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: <40D9BFAE.8060801@bitplanet.net> Message-ID: <20040623174729.614.qmail@web14930.mail.yahoo.com> 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_Hgsberg <krh@bitplanet.net> 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 > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg > ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <20040623174729.614.qmail@web14930.mail.yahoo.com> References: <20040623174729.614.qmail@web14930.mail.yahoo.com> Message-ID: <40D9C9F9.9010107@bitplanet.net> 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 <krh@bitplanet.net> 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 >>xorg@freedesktop.org >>http://freedesktop.org/mailman/listinfo/xorg >> > > > > ===== > Jon Smirl > jonsmirl@yahoo.com > > > > > __________________________________ > 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: <20040623143703.GA6420@kem.org> References: <20040623031836.GB31076@kem.org> <Pine.LNX.4.44.0406231115550.29553-100000@harrier.dpmms.cam.ac.uk> <20040623143703.GA6420@kem.org> Message-ID: <40D9CC4E.6070008@us.ibm.com> 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: <40D9CC4E.6070008@us.ibm.com> References: <20040623031836.GB31076@kem.org> <Pine.LNX.4.44.0406231115550.29553-100000@harrier.dpmms.cam.ac.uk> <20040623143703.GA6420@kem.org> <40D9CC4E.6070008@us.ibm.com> Message-ID: <20040623184023.GA10899@kem.org> 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: <40D9C9F9.9010107@bitplanet.net> Message-ID: <20040623185212.21538.qmail@web14929.mail.yahoo.com> --- Kristian Hgsberg <krh@bitplanet.net> 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 jonsmirl@yahoo.com __________________________________ 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: <40D9BFAE.8060801@bitplanet.net> References: <40D9BFAE.8060801@bitplanet.net> Message-ID: <Pine.LNX.4.56.0406240001070.19313@grok.cs.huji.ac.il> 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 > xorg@freedesktop.org > 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: <20040623212543.17851.qmail@web14926.mail.yahoo.com> 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 jonsmirl@yahoo.com __________________________________ 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: <Pine.LNX.4.56.0406240001070.19313@grok.cs.huji.ac.il> References: <40D9BFAE.8060801@bitplanet.net> <Pine.LNX.4.56.0406240001070.19313@grok.cs.huji.ac.il> Message-ID: <40DA19AF.9040209@bitplanet.net> 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 >>xorg@freedesktop.org >>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: <40DA4246.3030608@monochromatic.net> 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: <31058754212B50469824909BE90A4CFB0C7474@ILEX2.IL.NDS.COM> 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 postmaster@nds.com 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: <1088004325.27145.44.camel@circle.hypercube> References: <1088004325.27145.44.camel@circle.hypercube> Message-ID: <1088090530.2037.7.camel@circle.hypercube> 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." <40D9BFAE.8060801@bitplanet.net> Message-ID: <E1BdfYK-0000UK-Kd@evo.keithp.com> 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." <Pine.LNX.4.56.0406240001070.19313@grok.cs.huji.ac.il> Message-ID: <E1Bdfff-0000Vx-Kx@evo.keithp.com> 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: <1088127859.2643.199140552@webmail.messagingengine.com> Just another try. Hope that someone can clue me in. Thanks. Asterius. On Tue, 22 Jun 2004 18:19:06 -0800, "Asterius Pandoras" <asterius@airpost.net> 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 > xorg@freedesktop.org > 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." <1088127859.2643.199140552@webmail.messagingengine.com> Message-ID: <E1Bdfqm-0000hE-SK@evo.keithp.com> 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: <31058754212B50469824909BE90A4CFB0C7474@ILEX2.IL.NDS.COM> 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" <yernst@ndsisrael.com> To: <xorg@freedesktop.org> 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 postmaster@nds.com and destroy the original message. > ******************************************************************************** *** > -------------------------------------------------------------------------------- > _______________________________________________ > xorg mailing list > xorg@freedesktop.org > 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: <Pine.LNX.4.58.0406251329220.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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" <carl@personnelware.com> To: <xorg@freedesktop.org> 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 > xorg@freedesktop.org > 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: <20040625121322.GM21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40DB03EC.8080503@niehs.nih.gov> References: <40D9BFAE.8060801@bitplanet.net> <40DB03EC.8080503@niehs.nih.gov> Message-ID: <40DC2D3E.40209@bitplanet.net> [ 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: <Pine.LNX.4.58.0406251711590.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <1083691846.7905.97.camel@finch.boston.redhat.com> References: <200404291502.21532.jbarnes@engr.sgi.com> <1083691846.7905.97.camel@finch.boston.redhat.com> Message-ID: <200406251300.56991.jbarnes@sgi.com> 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: <40DC2D3E.40209@bitplanet.net> References: <40D9BFAE.8060801@bitplanet.net> <40DB03EC.8080503@niehs.nih.gov> <40DC2D3E.40209@bitplanet.net> Message-ID: <40DC98FC.6090008@niehs.nih.gov> 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: <1088208475.28180.199205223@webmail.messagingengine.com> 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: <1088208475.28180.199205223@webmail.messagingengine.com> 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: <1088208475.28180.199205223@webmail.messagingengine.com> References: <1088208475.28180.199205223@webmail.messagingengine.com> Message-ID: <20040626042525.GQ21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40DD937F.10506@toya.net.pl> #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: <40DD937F.10506@toya.net.pl> References: <40DD937F.10506@toya.net.pl> Message-ID: <20040626160129.GR21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <Pine.GSO.4.58.0406261923350.29784@thanatos.csd.uoc.gr> 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: <20040626160129.GR21053@fooishbar.org> References: <40DD937F.10506@toya.net.pl> <20040626160129.GR21053@fooishbar.org> Message-ID: <40DDD288.7050802@toya.net.pl> 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: <1088296150.7775.199240845@webmail.messagingengine.com> 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: <E1BeS2u-0002MP-CM@evo.keithp.com> 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: <40DDD288.7050802@toya.net.pl>; from loc@toya.net.pl on Sat, Jun 26, 2004 at 09:46:16PM +0200 References: <40DD937F.10506@toya.net.pl> <20040626160129.GR21053@fooishbar.org> <40DDD288.7050802@toya.net.pl> Message-ID: <20040627153046.E60251@artificial-stupidity.net> 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: <200406271747.23883.erik_hb_mlist@yahoo.com.au> 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: <200406271747.23883.erik_hb_mlist@yahoo.com.au> References: <200406271747.23883.erik_hb_mlist@yahoo.com.au> Message-ID: <20040627090003.GA25805@suse.de> 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 (martr@zeelandnet.nl) Date: Sun Jun 27 05:27:43 2004 Subject: [Xorg] X11R6.7.0 on HP-UX; X Errors. Message-ID: <20040627142738.739e0009.martr@zeelandnet.nl> 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: <40DEE55D.2010806@toya.net.pl> 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: <40DEE55D.2010806@toya.net.pl> References: <40DEE55D.2010806@toya.net.pl> Message-ID: <20040627152330.GC21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40DEF555.6060101@toya.net.pl> References: <40DEE55D.2010806@toya.net.pl> <20040627152330.GC21053@fooishbar.org> <40DEF555.6060101@toya.net.pl> Message-ID: <20040627164623.GD21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40DF2BA3.2000606@toya.net.pl> 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: <40DF2BA3.2000606@toya.net.pl> References: <40DF2BA3.2000606@toya.net.pl> Message-ID: <20040627202336.GF21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040627202336.GF21053@fooishbar.org> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> Message-ID: <40DF2F7A.8010000@toya.net.pl> 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: <40DF2F7A.8010000@toya.net.pl> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> Message-ID: <20040627204101.GG21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040627204101.GG21053@fooishbar.org> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> Message-ID: <40DF7759.9020704@toya.net.pl> 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: <40DF7759.9020704@toya.net.pl> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> Message-ID: <20040628015657.GH21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40DC2D3E.40209@bitplanet.net> References: <40D9BFAE.8060801@bitplanet.net> <40DB03EC.8080503@niehs.nih.gov> <40DC2D3E.40209@bitplanet.net> Message-ID: <Pine.LNX.4.56.0406281101040.12734@grok.cs.huji.ac.il> 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: <20040628015657.GH21053@fooishbar.org> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> Message-ID: <40DFFBC2.9020700@toya.net.pl> 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: <40DFFBC2.9020700@toya.net.pl> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> Message-ID: <20040628111128.GJ21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <40DFFBC2.9020700@toya.net.pl> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> 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: <20040628111128.GJ21053@fooishbar.org> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> Message-ID: <40E006DA.8070800@toya.net.pl> 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: <Pine.LNX.4.44.0406281323050.24867-100000@maggie.lkpg.cendio.se> 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: <Pine.LNX.4.44.0406281323050.24867-100000@maggie.lkpg.cendio.se> References: <Pine.LNX.4.44.0406281323050.24867-100000@maggie.lkpg.cendio.se> Message-ID: <Pine.LNX.4.58.0406281506100.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <1088429587.2767.15.camel@mariusd.pasco.net> 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: <40E006DA.8070800@toya.net.pl> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> Message-ID: <20040628134838.GL21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <1088429587.2767.15.camel@mariusd.pasco.net> References: <1088429587.2767.15.camel@mariusd.pasco.net> Message-ID: <1088426782.28556.7.camel@localhost.localdomain> 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: <Pine.LNX.4.58.0406281506100.18487@odoaker.hrz.tu-chemnitz.de> Message-ID: <Pine.LNX.4.44.0406281544040.25673-100000@maggie.lkpg.cendio.se> 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: <Pine.LNX.4.44.0406281544040.25673-100000@maggie.lkpg.cendio.se> References: <Pine.LNX.4.44.0406281544040.25673-100000@maggie.lkpg.cendio.se> Message-ID: <Pine.LNX.4.58.0406281659470.18487@odoaker.hrz.tu-chemnitz.de> 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 -- Alexander.Gottwald@s1999.tu-chemnitz.de 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: <20040628134838.GL21053@fooishbar.org> References: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> Message-ID: <40E034AA.503@toya.net.pl> 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: <40E034AA.503@toya.net.pl> References: <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> Message-ID: <20040628151310.GM21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: krh@bitplanet.net wrote on Wednesday, 23 June 2004 at 19:36:46 +0200 References: <40D9BFAE.8060801@bitplanet.net> Message-ID: <16608.13960.685100.611357@hermes.local> 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: keithp@keithp.com wrote on Thursday, 24 June 2004 at 21:30:52 -0400 References: <40D9BFAE.8060801@bitplanet.net> <E1BdfYK-0000UK-Kd@evo.keithp.com> Message-ID: <16608.14200.939504.532986@hermes.local> 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: eta@lclark.edu wrote on Sunday, 20 June 2004 at 03:01:20 -0700 References: <20040618035403.GD3565@fooishbar.org> <Pine.LNX.4.44_heb2.09.0406181210210.21130-100000@grok.cs.huji.ac.il> <20040618091333.GG3565@fooishbar.org> <1087725680.1032.144.camel@leguin> Message-ID: <16608.14234.588291.119354@hermes.local> 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." <16608.13960.685100.611357@hermes.local> Message-ID: <E1Bey5F-0000Rj-Qz@evo.keithp.com> 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: <20040628151310.GM21053@fooishbar.org> References: <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> Message-ID: <40E03B63.2020104@toya.net.pl> 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: <40E03C57.5080608@toya.net.pl> References: <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> <40E038BB.7050005@toya.net.pl> <20040628153257.GN21053@fooishbar.org> <40E03C57.5080608@toya.net.pl> Message-ID: <20040628155417.GO21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <16608.15821.893814.352412@hermes.local> 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: <40E04A40.4060701@skewedperception.com> 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: keithp@keithp.com wrote on Monday, 28 June 2004 at 08:30:13 -0700 References: <16608.13960.685100.611357@hermes.local> <E1Bey5F-0000Rj-Qz@evo.keithp.com> Message-ID: <16608.21781.787339.407951@hermes.local> 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: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> 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: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> References: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> Message-ID: <20040628181625.GP21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <200406282023.26849.grifis87@virgilio.it> 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: <20040628181625.GP21053@fooishbar.org> References: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> <20040628181625.GP21053@fooishbar.org> Message-ID: <68890EB1-C931-11D8-A10A-00039390D626@pepper.com> 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 > <daniel@freedesktop.org> > 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: <200406282023.26849.grifis87@virgilio.it> References: <200406282023.26849.grifis87@virgilio.it> Message-ID: <20040628183224.GQ21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <68890EB1-C931-11D8-A10A-00039390D626@pepper.com> References: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> <20040628181625.GP21053@fooishbar.org> <68890EB1-C931-11D8-A10A-00039390D626@pepper.com> Message-ID: <20040628183314.GR21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040628183224.GQ21053@fooishbar.org> References: <200406282023.26849.grifis87@virgilio.it> <20040628183224.GQ21053@fooishbar.org> Message-ID: <200406282032.34320.grifis87@virgilio.it> 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: <20040628183314.GR21053@fooishbar.org> References: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> <20040628181625.GP21053@fooishbar.org> <68890EB1-C931-11D8-A10A-00039390D626@pepper.com> <20040628183314.GR21053@fooishbar.org> Message-ID: <99C09E2E-C932-11D8-A10A-00039390D626@pepper.com> 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 > <daniel@freedesktop.org> > 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: <200406282032.34320.grifis87@virgilio.it> References: <200406282023.26849.grifis87@virgilio.it> <20040628183224.GQ21053@fooishbar.org> <200406282032.34320.grifis87@virgilio.it> Message-ID: <20040628184404.GT21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <10E92333-C935-11D8-A10A-00039390D626@pepper.com> References: <EDE3BCAF-C92D-11D8-A10A-00039390D626@pepper.com> <20040628181625.GP21053@fooishbar.org> <68890EB1-C931-11D8-A10A-00039390D626@pepper.com> <20040628183314.GR21053@fooishbar.org> <99C09E2E-C932-11D8-A10A-00039390D626@pepper.com> <20040628184253.GS21053@fooishbar.org> <10E92333-C935-11D8-A10A-00039390D626@pepper.com> Message-ID: <20040628190103.GU21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040628183224.GQ21053@fooishbar.org> References: <200406282023.26849.grifis87@virgilio.it> <20040628183224.GQ21053@fooishbar.org> Message-ID: <200406282251.19421.grifis87@virgilio.it> 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: <20040628184404.GT21053@fooishbar.org> References: <200406282023.26849.grifis87@virgilio.it> <20040628183224.GQ21053@ fooishbar.org> <200406282032.34320.grifis87@virgilio.it> <20040628184404.GT21053@fooishbar.org> Message-ID: <40E08926.9070300@toya.net.pl> 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: <1088461710.12141.199348515@webmail.messagingengine.com> 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: <20040628155417.GO21053@fooishbar.org> References: <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> <40E038BB.7050005@toya.net.pl> <20040628153257.GN21053@fooishbar.org> <40E03C57.5080608@toya.net.pl> <20040628155417.GO21053@fooishbar.org> Message-ID: <40E0C59B.2050405@toya.net.pl> 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: <C6689B70-BFA6-11D8-852F-00039390D626@pepper.com> <1087425732.973.5.camel@leguin> Message-ID: <55D03654-C96C-11D8-9952-003065B218E0@pepper.com> 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." <55D03654-C96C-11D8-9952-003065B218E0@pepper.com> Message-ID: <E1Bf7el-0000Tf-Ek@evo.keithp.com> 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: <E1Bf7el-0000Tf-Ek@evo.keithp.com> References: <E1Bf7el-0000Tf-Ek@evo.keithp.com> Message-ID: <0C4F2C61-C96E-11D8-9952-003065B218E0@pepper.com> 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." <0C4F2C61-C96E-11D8-9952-003065B218E0@pepper.com> Message-ID: <E1Bf7ks-0000UW-59@evo.keithp.com> 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: <E1Bf7ks-0000UW-59@evo.keithp.com> References: <E1Bf7ks-0000UW-59@evo.keithp.com> Message-ID: <7D116F03-C96F-11D8-9952-003065B218E0@pepper.com> 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." <7D116F03-C96F-11D8-9952-003065B218E0@pepper.com> Message-ID: <E1Bf7ts-0000Vq-9K@evo.keithp.com> 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: <E1Bf7ts-0000Vq-9K@evo.keithp.com> References: <E1Bf7ts-0000Vq-9K@evo.keithp.com> Message-ID: <1CF5640A-C970-11D8-9952-003065B218E0@pepper.com> 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: <40E0C59B.2050405@toya.net.pl> References: <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> <40E038BB.7050005@toya.net.pl> <20040628153257.GN21053@fooishbar.org> <40E03C57.5080608@toya.net.pl> <20040628155417.GO21053@fooishbar.org> <40E0C59B.2050405@toya.net.pl> Message-ID: <20040629064819.GV21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <200406282251.19421.grifis87@virgilio.it> References: <200406282023.26849.grifis87@virgilio.it> <20040628183224.GQ21053@fooishbar.org> <200406282251.19421.grifis87@virgilio.it> Message-ID: <20040629064836.GW21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040629064819.GV21053@fooishbar.org> References: <20040628111128.GJ21053@fooishbar.org> <40E006DA.8070800@toya.net.pl> <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> <40E038BB.7050005@toya.net.pl> <20040628153257.GN21053@fooishbar.org> <40E03C57.5080608@toya.net.pl> <20040628155417.GO21053@fooishbar.org> <40E0C59B.2050405@toya.net.pl> <20040629064819.GV21053@fooishbar.org> Message-ID: <40E13393.8090506@toya.net.pl> 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: <E1BdfYK-0000UK-Kd@evo.keithp.com> References: <E1BdfYK-0000UK-Kd@evo.keithp.com> Message-ID: <40E13976.4080709@bitplanet.net> 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: <16608.14200.939504.532986@hermes.local> References: <40D9BFAE.8060801@bitplanet.net> <E1BdfYK-0000UK-Kd@evo.keithp.co m> <16608.14200.939504.532986@hermes.local> Message-ID: <40E13F9A.7030108@bitplanet.net> 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: <Pine.LNX.4.56.0406281101040.12734@grok.cs.huji.ac.il> References: <40D9BFAE.8060801@bitplanet.net> <40DB03EC.8080503@niehs.nih.gov> <40DC2D3E.40209@bitplanet.net> <Pine.LNX.4.56.0406281101040.12734@grok.cs.huji.ac.il> Message-ID: <40E1426B.9090604@bitplanet.net> 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: <40E1426B.9090604@bitplanet.net> References: <40D9BFAE.8060801@bitplanet.net> <40DB03EC.8080503@niehs.nih.gov> <40DC2D3E.40209@bitplanet.net> <Pine.LNX.4.56.0406281101040.12734@grok.cs.huji.ac.il> <40E1426B.9090604@bitplanet.net> Message-ID: <Pine.LNX.4.56.0406291323330.1813@typhoon-04.cs.huji.ac.il> 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: <16607.59124.921806.956671@hermes.local> References: <40D9BFAE.8060801@bitplanet.net> <16607.59124.921806.956671@hermes.local> Message-ID: <40E15455.9060104@bitplanet.net> 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: <16608.15821.893814.352412@hermes.local> References: <16608.15821.893814.352412@hermes.local> 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 anderson@netsweng.com 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: <40E13393.8090506@toya.net.pl> References: <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> <40E038BB.7050005@toya.net.pl> <20040628153257.GN21053@fooishbar.org> <40E03C57.5080608@toya.net.pl> <20040628155417.GO21053@fooishbar.org> <40E0C59B.2050405@toya.net.pl> <20040629064819.GV21053@fooishbar.org> <40E13393.8090506@toya.net.pl> Message-ID: <20040629141453.GZ21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <E1Bf7ts-0000Vq-9K@evo.keithp.com> References: <E1Bf7ts-0000Vq-9K@evo.keithp.com> Message-ID: <B9340A20-C9D6-11D8-A10A-00039390D626@pepper.com> 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: <40E18159.FCAC5F13@nrubsig.org> 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <31058754212B50469824909BE90A4CFBB6BB57@ILEX2.IL.NDS.COM> 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:yernst@ndsisrael.com> 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 postmaster@nds.com 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: <40E186BE.89043BC7@nrubsig.org> 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 xorg-commit@pdx.freedesktop.org... -- 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) roland.mainz@nrubsig.org \__\/\/__/ 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: <40E186BE.89043BC7@nrubsig.org> References: <40E186BE.89043BC7@nrubsig.org> Message-ID: <20040629151608.GB21053@fooishbar.org> 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 xorg-commit@pdx.freedesktop.org... > -- 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <20040629141453.GZ21053@fooishbar.org> References: <20040628134838.GL21053@fooishbar.org> <40E034AA.503@toya.net.pl> <20040628151310.GM21053@fooishbar.org> <40E038BB.7050005@toya.net.pl> <20040628153257.GN21053@fooishbar.org> <40E03C57.5080608@toya.net.pl> <20040628155417.GO21053@fooishbar.org> <40E0C59B.2050405@toya.net.pl> <20040629064819.GV21053@fooishbar.org> <40E13393.8090506@toya.net.pl> <20040629141453.GZ21053@fooishbar.org> Message-ID: <40E187C9.7010705@toya.net.pl> 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: <B9340A20-C9D6-11D8-A10A-00039390D626@pepper.com> References: <E1Bf7ts-0000Vq-9K@evo.keithp.com> <B9340A20-C9D6-11D8-A10A-00039390D626@pepper.com> Message-ID: <8D0EF8DF-C9DF-11D8-A10A-00039390D626@pepper.com> 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 > xorg@freedesktop.org > 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: <31058754212B50469824909BE90A4CFBB6BB59@ILEX2.IL.NDS.COM> Yehuda Ernst NDS Technologies Israel Ltd. mailto:yernst@ndsisrael.com> 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 postmaster@nds.com 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: <8D0EF8DF-C9DF-11D8-A10A-00039390D626@pepper.com> References: <E1Bf7ts-0000Vq-9K@evo.keithp.com> <B9340A20-C9D6-11D8-A10A-00039390D626@pepper.com> <8D0EF8DF-C9DF-11D8-A10A-00039390D626@pepper.com> Message-ID: <1088522150.32425.7.camel@localhost.localdomain> 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: <40E1ACD4.9040805@Sun.COM> -------- Original Message -------- Subject: Project Looking Glass Open Source Announcement Date: Tue, 29 Jun 2004 10:46:06 -0700 From: Lauren Zuravleff <Lauren.Zuravleff@Sun.COM> Reply-To: Lauren.Zuravleff@Sun.COM To: looking-glass-interest@Sun.COM 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 lg3d_license@dev.java.net. 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: project-looking-glass@sun.com 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: <40E1ACD4.9040805@Sun.COM> References: <40E1ACD4.9040805@Sun.COM> Message-ID: <1088532247.28761.1.camel@atlantis.netenviron.com> 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 <torgeir@pobox.com> 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: <1088532247.28761.1.camel@atlantis.netenviron.com> References: <40E1ACD4.9040805@Sun.COM> <1088532247.28761.1.camel@atlantis.netenviron.com> Message-ID: <a728f9f9040629110841ab168c@mail.gmail.com> On Tue, 29 Jun 2004 19:04:06 +0100, Torgeir Veimo <torgeir@pobox.com> 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 <torgeir@pobox.com> > 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: <a728f9f9040629110841ab168c@mail.gmail.com> References: <40E1ACD4.9040805@Sun.COM> <1088532247.28761.1.camel@atlantis.netenviron.com> <a728f9f9040629110841ab168c@mail.gmail.com> Message-ID: <20040629181205.GL21053@fooishbar.org> On Tue, Jun 29, 2004 at 02:08:03PM -0400, Alex Deucher wrote: > On Tue, 29 Jun 2004 19:04:06 +0100, Torgeir Veimo <torgeir@pobox.com> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <1088532247.28761.1.camel@atlantis.netenviron.com> References: <40E1ACD4.9040805@Sun.COM> <1088532247.28761.1.camel@atlantis.netenviron.com> Message-ID: <40E1B2BD.7000803@Sun.COM> 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- alan.coopersmith@sun.com 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: <20040629181205.GL21053@fooishbar.org> References: <40E1ACD4.9040805@Sun.COM> <1088532247.28761.1.camel@atlantis.netenviron.com> <a728f9f9040629110841ab168c@mail.gmail.com> <20040629181205.GL21053@fooishbar.org> Message-ID: <40E1B382.6010505@Sun.COM> 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 <torgeir@pobox.com> 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- alan.coopersmith@sun.com 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: <40E15455.9060104@bitplanet.net> Message-ID: <20040629184439.85565.qmail@web14928.mail.yahoo.com> --- Kristian Hgsberg <krh@bitplanet.net> wrote: > > While currently it is not possible to run multiple X servers on the > > same system (multi seat) it might well be in the future. In this > > case it must be made sure that only one of these servers connects > to > > the device and that after a replug the same server gets the device > > reassigned. > > Yeah, that's a good point. The discovery mechanism should remember > which server to add the device to. This needs to be part of a bigger design, probably using udev. fbdev has the same problem and we don't want to build two parallel systems for assigning devices. One solution would be to tag device with a console id in udev.conf -- console 0, 1, 2, etc and assign each xserver a console id too. The hotplug program could then match the device to the correct xserver. Instead of making up console ids you could use the dri device number. ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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." <B9340A20-C9D6-11D8-A10A-00039390D626@pepper.com> Message-ID: <E1BfNau-0000Wy-Na@evo.keithp.com> 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." <40E186BE.89043BC7@nrubsig.org> Message-ID: <E1BfNdF-0000Xj-4P@evo.keithp.com> 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: <E1BfNdF-0000Xj-4P@evo.keithp.com> References: <40E186BE.89043BC7@nrubsig.org> <E1BfNdF-0000Xj-4P@evo.keithp.com> Message-ID: <20040629185009.GM21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <E1BfNau-0000Wy-Na@evo.keithp.com> References: <E1BfNau-0000Wy-Na@evo.keithp.com> Message-ID: <848AE960-C9FD-11D8-A10A-00039390D626@pepper.com> 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." <1088522150.32425.7.camel@localhost.localdomain> Message-ID: <E1BfNnC-0000bf-N1@evo.keithp.com> 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: <40E1BCED.7060705@Sun.COM> 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 issues@lg3d-core.dev.java.net. 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 deron.johnson@sun.com (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." <848AE960-C9FD-11D8-A10A-00039390D626@pepper.com> Message-ID: <E1BfNwG-0000h6-8E@evo.keithp.com> 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: <40E1BCED.7060705@Sun.COM> Message-ID: <40E1BF29.2070607@Sun.COM> 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 > issues@lg3d-core.dev.java.net. > > 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 > deron.johnson@sun.com > (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: <40E1ACD4.9040805@Sun.COM> References: <40E1ACD4.9040805@Sun.COM> Message-ID: <40E1BE14.8040409@tungstengraphics.com> Alan Coopersmith wrote: > > > -------- Original Message -------- > Subject: Project Looking Glass Open Source Announcement > Date: Tue, 29 Jun 2004 10:46:06 -0700 > From: Lauren Zuravleff <Lauren.Zuravleff@Sun.COM> > Reply-To: Lauren.Zuravleff@Sun.COM > To: looking-glass-interest@Sun.COM > > 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: <E1BfNnC-0000bf-N1@evo.keithp.com> Message-ID: <20040629191430.18999.qmail@web14927.mail.yahoo.com> --- Keith Packard <keithp@keithp.com> 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 > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg > ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <E1BfNnC-0000bf-N1@evo.keithp.com> Message-ID: <20040629191630.33154.qmail@web14921.mail.yahoo.com> 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 <keithp@keithp.com> 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 > xorg@freedesktop.org > http://freedesktop.org/mailman/listinfo/xorg > ===== Jon Smirl jonsmirl@yahoo.com __________________________________ 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: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <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 eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org 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: <40DF2BA3.2000606@toya.net.pl> <20040627202336.GF21053@fooishbar.org> <40DF2F7A.8010000@toya.net.pl> <20040627204101.GG21053@fooishbar.org> <40DF7759.9020704@toya.net.pl> <20040628015657.GH21053@fooishbar.org> <40DFFBC2.9020700@toya.net.pl> <1088421789.17763.26.camel@localhost> <1088526951.1134.8.camel@abbey> Message-ID: <20040629192117.GN21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <31058754212B50469824909BE90A4CFBB6BB57@ILEX2.IL.NDS.COM> 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: <20040629204214.GA2241@snoopy.folie> 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: <200406251300.56991.jbarnes@sgi.com> References: <200404291502.21532.jbarnes@engr.sgi.com> <1083691846.7905.97.camel@finch.boston.redhat.com> <200406251300.56991.jbarnes@sgi.com> Message-ID: <200406291350.25056.jbarnes@engr.sgi.com> 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; +}
- 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: <89E6B3C2-CA14-11D8-A10A-00039390D626@pepper.com> 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: <E1BfNwG-0000h6-8E@evo.keithp.com> References: <E1BfNwG-0000h6-8E@evo.keithp.com> Message-ID: <Pine.LNX.4.58.0406291822580.29778@paert.nvidia.com> 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: <20040629151608.GB21053@fooishbar.org> References: <40E186BE.89043BC7@nrubsig.org> <20040629151608.GB21053@fooishbar.org> Message-ID: <Pine.LNX.4.56.0406301202390.19103@grok.cs.huji.ac.il> 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 xorg-commit@pdx.freedesktop.org... > > -- 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 <daniel@freedesktop.or 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: <20040629151608.GB21053@fooishbar.org> References: <40E186BE.89043BC7@nrubsig.org> <20040629151608.GB21053@fooishbar.org> Message-ID: <40E2D2B5.9020709@tungstengraphics.com> 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 xorg-commit@pdx.freedesktop.org... >>-- 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: anderson@netsweng.com wrote on Tuesday, 29 June 2004 at 05:20:19 -0400 References: <16608.15821.893814.352412@hermes.local> <Pine.LNX.4.56.0406290518560.1976@localhost> Message-ID: <16610.56341.297625.673232@xf11.fra.suse.de> 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: <16610.56341.297625.673232@xf11.fra.suse.de> References: <16608.15821.893814.352412@hermes.local> <Pine.LNX.4.56.0406290518560.1976@localhost> <16610.56341.297625.673232@xf11.fra.suse.de> 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 anderson@netsweng.com 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: <2340D02E-CAAC-11D8-8AC4-00039390D626@pepper.com> 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: <95591AC0-CAC2-11D8-8AC4-00039390D626@pepper.com> 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: <95591AC0-CAC2-11D8-8AC4-00039390D626@pepper.com> References: <95591AC0-CAC2-11D8-8AC4-00039390D626@pepper.com> Message-ID: <Pine.LNX.4.56.0406302217030.5410@grok.cs.huji.ac.il> 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 > xorg@freedesktop.org > 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: <Pine.LNX.4.56.0406302217030.5410@grok.cs.huji.ac.il> References: <95591AC0-CAC2-11D8-8AC4-00039390D626@pepper.com> <Pine.LNX.4.56.0406302217030.5410@grok.cs.huji.ac.il> Message-ID: <41D60B8F-CACA-11D8-8AC4-00039390D626@pepper.com> 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 >> xorg@freedesktop.org >> 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: <41D60B8F-CACA-11D8-8AC4-00039390D626@pepper.com> References: <95591AC0-CAC2-11D8-8AC4-00039390D626@pepper.com> <Pine.LNX.4.56.0 406302217030.5410@grok.cs.huji.ac.il> <41D60B8F-CACA-11D8-8AC4-00039390D626@pepper.com> Message-ID: <40E325F5.4050505@niehs.nih.gov> 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: <20040629191430.18999.qmail@web14927.mail.yahoo.com> References: <20040629191430.18999.qmail@web14927.mail.yahoo.com> Message-ID: <1088633198.2102.15.camel@localhost.localdomain> 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: <40E2D2B5.9020709@tungstengraphics.com> References: <40E186BE.89043BC7@nrubsig.org> <20040629151608.GB21053@fooishbar.org> <40E2D2B5.9020709@tungstengraphics.com> Message-ID: <20040701032446.GU21053@fooishbar.org> 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 <daniel@freedesktop.org> freedesktop.org: powering your desktop http://www.freedesktop.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://freedesktop.org/pipermail/xorg/attachments/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: <1088660842.9818b11cplazmatikz_nz@myrealbox.com> 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: <1087511254.28382.198661593@webmail.messagingengine.com> References: <1087511254.28382.198661593@webmail.messagingengine.com> Message-ID: <1087568725.2168.5.camel@localhost.localdomain> 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