CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/27 16:07:07 Log message: 409. SiS driver: Add RENDER hardware acceleration Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.2832+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/27 16:32:51 Log message: 409. Added RENDER hw acceleration Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis.h sis310_accel.c sis310_accel.h sis_dri.c sis_driver.c sis_setup.c Revision ChangesPath 1.51 +3 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.18 +73 -56xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.11 +10 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.h 1.31 +1 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_dri.c 1.116 +23 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.18 +15 -8 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_setup.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/27 17:35:24 Log message: Previous version still not quite right. Modified files: xc/lib/xtrans/: Xtransint.h Revision ChangesPath 3.41 +2 -3 xc/lib/xtrans/Xtransint.h ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/28 04:16:42 Log message: Add option NoRenderAcceleration; code clean-ups Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c sis.h sis310_accel.c sis310_accel.h sis_cursor.c sis_driver.c sis_opt.c Revision ChangesPath 1.17 +16 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.52 +2 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.19 +4 -5 xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.c 1.12 +71 -72xc/programs/Xserver/hw/xfree86/drivers/sis/sis310_accel.h 1.17 +5 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_cursor.c 1.117 +7 -4 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.28 +19 -0 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/28 06:21:17 Log message: Code clean-ups Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: init.c init.h sis.h sis_driver.c sis_video.c Revision ChangesPath 1.18 +6 -1479 xc/programs/Xserver/hw/xfree86/drivers/sis/init.c 1.19 +1 -40 xc/programs/Xserver/hw/xfree86/drivers/sis/init.h 1.53 +25 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis.h 1.118 +5 -3 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_driver.c 1.24 +49 -1 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_video.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/28 06:30:22 Log message: Typo in option name Modified files: xc/programs/Xserver/hw/xfree86/drivers/sis/: sis_opt.c Revision ChangesPath 1.29 +8 -7 xc/programs/Xserver/hw/xfree86/drivers/sis/sis_opt.c ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/08/28 09:11:32 Log message: Small simplification Modified files: xc/programs/twm/: Imakefile Revision ChangesPath 3.15 +2 -2 xc/programs/twm/Imakefile ___ Cvs-commit mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/cvs-commit
Re: RENDER question
On Wed, 27 Aug 2003 20:21:37 +0200 Thomas Winischhofer [EMAIL PROTECTED] (Bbabbled: (B (B Carsten Haitzler (The Rasterman) wrote: (B please please please PLEASE! accelerate everythig you can :) (B (B http://www.rasterman.com/files/render_bench.tar.gz (B (B Is it correct to assume, that the image I see over a rainbow-like (B background is the result of RENDER, and over a grey-shaded background (B from imlib? (B (Bcheck the .png's in the directory. (B (Btst_opaque.png (Bis set as the background to the window before doing any compositing and testing. (Bthis is done for both xrender and imlib2. it' sjust a "test background". (B (Btst_transparent.png (Bis what is blended and scaled on-top. :) (B (Byou will notice for about 2 seconds after each imlib2 test completes it displays (Bits work on the screen in the window. this is just to let you know that imlib2 (Bdid the right thing. (B (Bthe code is fairly straight-forward and modular too if you want to fiddle with (Bit, disable tests for now etc. (B (B If so, it looks good for RENDER accel for the SiS driver... (erm, well, (B unscaled yet) (B (Bgood... and scaled woudl be lurvely! :) (B (B Thomas (B (B (B -- (B Thomas Winischhofer (B Vienna/Austria (B thomas AT winischhofer DOT net *** http://www.winischhofer.net/ (B twini AT xfree86 DOT org (B (B (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 28 Aug 2003 03:30:18 +0200 Thomas Winischhofer [EMAIL PROTECTED] (Bbabbled: (B (B Carsten Haitzler (The Rasterman) wrote: (B The non-scaled onscreen XRender went from 9.7 to 0.7 seconds... :) (B (imlib is at 2.3 seconds). The scaled versions are not accelerated, and (B they all are much slower than Xrender... (B (B cool. though 0.7 vs 2.3 for imlib2 still isn't that good. i'd expect (B hardware to be a factor of 10 or more faster these days. from having used (B opengl in evas (as opposed to imlib2 in the older code engine) on a geforce1 (B i was getting easily 20 times speedups for such ops. (B (B The hardware I am working with is not famous for being fast, and it uses (B a shared framebuffer architecture. I stopped dreaming about miracles a (B long time ago. (I think that was when I found out that drawing (B trapezoids using the engine is slower than doing it by the CPU) (B (Bah shared framebuffer. ok. then i can understand some of the "hurt" :) (B (B What values do you get on your hardware? (Unscaled only, the rest is (B entirely depending on the CPU) (B (Bfor the benchmarker: (B*** ROUND 1 *** (B--- (BTest: Test Xrender doing non-scaled Over blends (BTime: 12.445 sec. (B--- (BTest: Test Xrender (offscreen) doing non-scaled Over blends (BTime: 10.056 sec. (B--- (BTest: Test Imlib2 doing non-scaled Over blends (BTime: 0.332 sec. (B (B(xrender doesnt have accel turned on there. if i turn it on it bats imlib 2 by (B3-4 times. i cant get to that box right now... thanks to my isp being screwed) (B:) (B (Bi dont have the old code working anymore for the gl engine i had - i just (Bremember getting full screen 1600x1200 composities and scales going from (Bsomewhere like 2 to 50+ fps once opengl got slid under the bonnet. (B (B basically - avoid copying the pixel data aroudn or changing its format if (B you (B (B Yey, thanks for enlighting me :) (B (Bok... yes it was obvious - but i remember one driver would copy the pixeldata (Btoa texture on EACH composite, THEN composite. :) (B (B can (ie if you put it through the 3d engine you may have to reformat the (B pixels due to in-memory texture formats being "strange"). so i'd try and (B keep the pixels wherever they were last in the format they were in last - (B all the time, so a blend or scaled composite/blend is literally 1 hardware (B op and not much more. (B (B I need to copy the texture to video RAM once, unless somebody tells me (B it already is there (I could use the 2D accelerator for this, too, then. (B In this case I just wonder why the mga driver doesn't do it this way.). (B (Bis this per composite? or just the first time it (the pixmap lets say) is (Bcreated? (B (B Since the accelerator does not sync after initiating the command, using (B the provided memory area is unsecure. The app might reuse it for (B something else before the command is actually executed. Syncing after (B the command is insane (because it could take forever, depending on the (B amount of commands already in the queue - and this queue is BIG) (B (Bhmmm do you have a way of knowing where the accelerator is up to? ie interrupts (Betc? or every time you put somehting on the end of the pipeline query where its (Bup to? so then the next gfx op you do you know if that memory region is (Bvalid/invalid and you can happily do other things with it... (B (B i don't actually know how you are doing it currently, so i'm just saying (B this as a general thing - but somehow i'd still expect hardware to be more (B than 3.3 times faster than the cpu :) (B (B It's a fast CPU with fast RAM, and a slow GPU with memory shared with (B the CPU. More can't be expected, I guess. (B (B2.3 seconds for a blend doesnt smell like a fast cpu :) my 1.7ghz athlon gets (Bthe 1:1 blends done in 0.3 secs or so. so technically my desktop cpu (ram/bus (Betc.) is still double the speed of your sis gfx chips :) (B (B Text drawing (x11perf -aa24text) went from 25000 to 105000, which is (B more than factor 4. I am satisfied. (Now, if I just could find out why (B the accelerator functions are not being called on my 4.3 system...) (B (Bthats good :) though i still like to compare x performance against external code (B(ie like imlib2 - or use gdk-pixbuf, or anything else) and always try to at (Bleast equal your "software rivals" :) i really want to see x accelerating where (Bhardware can and beating the PANTS off any software code :) (B (B Since the hardware I' dealing with supports stretched bitblits, I'll (B look if that could be made of any use. (B (B ich freue mich schon darauf :) (B (B You live in Australia, have a german sounding name, speak German... any (B special reason for (B using this icky JP font? (B
Re: RENDER question
On Thu, 2003-08-28 at 03:30, Thomas Winischhofer wrote: I need to copy the texture to video RAM once, unless somebody tells me it already is there (I could use the 2D accelerator for this, too, then. In this case I just wonder why the mga driver doesn't do it this way.). Because the mga driver RENDER acceleration is just a proof of concept hack? :) Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. Err, I get without acceleration on a 1 Ghz TiBook: 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line (Charter 24) Did you drop some digits? :) (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) I guess it's not the op being something else than PictOpOver? Could it be related to XAA_RENDER_NO_SRC_ALPHA? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 2003-08-28 at 15:58, Thomas Winischhofer wrote: Michel Dnzer wrote: Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. Err, I get without acceleration on a 1 Ghz TiBook: 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line (Charter 24) Interesting. What do -shmput500 -rect500 -oddtilerect500 give you on that machine? 2 reps @ 0.3149 msec ( 3180.0/sec): 500x500 rectangle 1 reps @ 0.5198 msec ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) 800 reps @ 7.1992 msec ( 139.0/sec): ShmPutImage 500x500 square (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) I guess it's not the op being something else than PictOpOver? Could it be related to XAA_RENDER_NO_SRC_ALPHA? They are called under 4.2, but not under 4.3. Does the server make the difference, or the libraries? Have you traced the X server which would call them? Maybe freetype (which I use the Debian sid version of) needs to be recompiled for 4.3. I don't think freetype is directly related to this, do you mean Xft? -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
Michel Dnzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Why the h*ck is render so fast on your machine? One possibility is that doing it unaccelerated requires the CPU to read from video RAM, which is terribly slow on my shared-memory architecture machine. dga (by pressing b) reports about 500MB/sec for writing, and only 37MB/sec for reading. Perhaps the 2D engine suffers from the same bottle-neck when doing the alpha blending... (Now, if I just could find out why the accelerator functions are not being called on my 4.3 system...) I guess it's not the op being something else than PictOpOver? Could it be related to XAA_RENDER_NO_SRC_ALPHA? I hadn't even set this until this morning. (In my tests, source alpha was never used as logging the calls showed). They are called under 4.2, but not under 4.3. Does the server make the difference, or the libraries? Have you traced the X server which would call them? Qt (current debian version) never uses them, be it under 4.2 or 4.3. (One SuSE user reported they do on his system, though). OpenOffice (current Debian version) uses them under both 4.2 and 4.3. Perhaps they have their own routines? Frankly, I think it's only related to my inconsistent setup (Debian SID, 4.3 binaries from XFree.org copied over the 4.2 setup). I wouldn't bother too much about this. Maybe freetype (which I use the Debian sid version of) needs to be recompiled for 4.3. I don't think freetype is directly related to this, do you mean Xft? Well, I confess, I am not an expert on these hundreds of libraries involved with text rendering :) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86, DRI, and multiple heads: thoughts and ideas
Alex Deucher wrote: Next, mergedfb... I've been thinking about creating generic xfree support functions to replace the chipset specific ones for mergedfb. This would make it easier to add mergedfb to other chipsets that support dualhead. Where should this live? also, as far as pseudo-xinerama, should that be made part of the generic mergedfb code or part of xinerama proper? i.e., to extend xinerama to handle both multi-card and single card xinerama. Or is all of this going to be refactored in xfree 5? IMHO, pseudo-Xinerama as we have it today is far from being perfect, partly because MergedFB mode does not fit into the Xinerama idea of two fixed-sized screens (RandR ignored here) with a fixed boundary between them. I'd prefer extending Xinerama for MergedFB specifics instead, and removing that pseudo-stuff in the long term. However, this would require some enhancements for the Xinerama extension (signals to clients, etc). That is, if at all, XF5 material, I guess. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
Michel Dänzer [EMAIL PROTECTED] writes: Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. Err, I get without acceleration on a 1 Ghz TiBook: 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line (Charter 24) Did you drop some digits? :) If we assume that each character is 10 by 24 pixels on the average, then your number corresponds to 369.6 Mpixels/s. FWIW, I get numbers comparable to Thomas' with an Nvidia Geforce 2, a 1GHz CPU, and a stock Red Hat 9 server using the free driver: 96000 reps @ 0.0628 msec ( 15900.0/sec): Char in 30-char aa line (Charter 24) Søren ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Unfortunately no. What we probably need is a Registry for known devices. However the naming sceme needs to be generic enough to also hold enough information so that if a device is not known to an application that the application can do something useful with it. you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... Or a hirachy. Input devices are a rather wide area. I have difficulties to overlook what all may be required, but when we extend the XInput extension we must be careful not to impose limits like the old one did. The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... Yes. Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. These would be properties. Properties can be accumulated, types are exclusive. I don't know if we can manage to characterize all device properties completely and if this is desirable. In many cases we may just be able to supply coordinates and the application needs to be configured to know what to do with these. A heirarchical system is the way to go. Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. It may or may not be. Input devices are not tablets only. Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS or XI_ERASER? We might expand the _XDeviceInfo struct to contain information about grouping if that's desired. This could be implemented quite
Re: RENDER question
Soeren Sandmann wrote: FWIW, I get numbers comparable to Thomas' with an Nvidia Geforce 2, a 1GHz CPU, and a stock Red Hat 9 server using the free driver: 96000 reps @ 0.0628 msec ( 15900.0/sec): Char in 30-char aa line (Charter 24) Well, now I feel good again with my 105000/sec here :) Thanks Søren and Aidan. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86, DRI, and multiple heads: thoughts and ideas
I was leaning that way myself... Alex --- Thomas Winischhofer [EMAIL PROTECTED] wrote: Alex Deucher wrote: Next, mergedfb... I've been thinking about creating generic xfree support functions to replace the chipset specific ones for mergedfb. This would make it easier to add mergedfb to other chipsets that support dualhead. Where should this live? also, as far as pseudo-xinerama, should that be made part of the generic mergedfb code or part of xinerama proper? i.e., to extend xinerama to handle both multi-card and single card xinerama. Or is all of this going to be refactored in xfree 5? IMHO, pseudo-Xinerama as we have it today is far from being perfect, partly because MergedFB mode does not fit into the Xinerama idea of two fixed-sized screens (RandR ignored here) with a fixed boundary between them. I'd prefer extending Xinerama for MergedFB specifics instead, and removing that pseudo-stuff in the long term. However, this would require some enhancements for the Xinerama extension (signals to clients, etc). That is, if at all, XF5 material, I guess. Thomas __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Let me finish by saying that even though I have never had my hands deep in the code of X, of course I'd be happy to help out - if doing a little coding in X makes my port of the toolkit go smoother it's definetely worth the effort. All I need to have is a consensus on what we want. Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. What I want to see is a unified system to configuring the input device. For example, under Linux USB/HID, you're not going to send a sequence to the tablet to switch between relative and absolute coordinates. Unless of course you also wrote the kernel device driver and somehow know how. Which I did and I do, but I've been known to cheat :-) -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On 26 Aug 2003, John Dennis wrote: The PCI configuration does provide various pieces of information which help determine how the device can be accessed, e.g. pre-fetch, latency, cache line size etc. All of this is available to firmware. Wouldn't all this be sufficient for firmware to make the right decisions? Yes and no. EFI also needs to always do the right thing, which is to ensure all BAR and ROM pointer assignments are valid. For XFree86, this includes all graphics devices, not just the active ones. And the kernel likely has other ideas on this too. If re-assignments are ever needed (by the kernel or XFree86), mayhem is likely to occur. Secondly, EFI is already doing the wrong thing by marking PCI ROMs as non-cacheable. This doesn't inspire confidence... It occurs to me that we should probably change XAA to flush CPU caches just after calling the driver's Sync() function, and change mibank to do the same after telling the driver to switch banks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: a small twm/Imakefile patch
On 20 Jul 2003, Alexander Pohoyda wrote: With your change, on IRIX, I get: [aurora:/scratch_large/root/X11/alpha/loader/xc/programs] make SUBDIRS=twm Makefiles making Makefiles in programs/twm... mv -f Makefile Makefile.bak cc-1018 cc: ERROR at end of source An unmatched left parentheses ( appears in an expression. Would you please try if it works on IRIX this way: -SpecialCObjectRule(parse,$(_NOOP_),'-DSYSTEM_INIT_FILE='$(TWMDIR)'/system.twmrc') +SpecialCObjectRule(parse,$(_NOOP_),'-DSYSTEM_INIT_FILE=$(TWMDIR)/system.twmrc') Yes, that works. It's not about commiting this senseless patch, of course :-) I did so anyway. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Heh. In my spare time, I'll put something together. But things of value that I'm looking at, 1) A layer that can configure/inspect the driver (e.g., it handles everything in the XF86Config file, bidirectionally). Which fits right into making that puppy modular/enterprise controllable. 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. 3) An external event interface. Basically your hotplug events, although I'd like to extend that to supporting a conversation like, well, a tablet's now plugged in; you have no tablet drivers loaded now. The tablet's identified by 'blahblahblah'. Figure out which driver that corresponds to, load yourself with default settings 4) Then, some level of user-customizable API. E.g., all parameters have names that are converted to Atoms, whose values are type-safely converted back and forth. Gad, it sounds like SOAP / XML/RPC! Maybe it is... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 2003-08-28 at 16:51, Thomas Winischhofer wrote: Michel Dnzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Well, 32 bit PowerPC CPUs aren't exactly famous for memory throughput. :( This is even accelerated via AGP by the chip's DMA engine, otherwise I only get around 50. Why the h*ck is render so fast on your machine? Beats me. One possibility is that doing it unaccelerated requires the CPU to read from video RAM, Indeed, it does AFAIK. which is terribly slow on my shared-memory architecture machine. dga (by pressing b) reports about 500MB/sec for writing, and only 37MB/sec for reading. Perhaps the 2D engine suffers from the same bottle-neck when doing the alpha blending... Sounds plausible. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
TAYLOR
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
On Thu, 2003-08-28 at 17:59, Egbert Eich wrote: Claus Matthiesen writes: Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Unfortunately no. What we probably need is a Registry for known devices. However the naming sceme needs to be generic enough to also hold enough information so that if a device is not known to an application that the application can do something useful with it Actually, I'm really getting into the idea that the device can sort of tell the application how to interpret its data. I'll elaborate later in the mail... you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. As I was trying to find some clever way of making a general structure without using a hierachy, I realized that that probably is the easiest, most future-secure way of doing it. Alright, you convinced me. (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... Or a hirachy. Input devices are a rather wide area. I have difficulties to overlook what all may be required, but when we extend the XInput extension we must be careful not to impose limits like the old one did. Yes, yes! You already swayed me! :-) But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... Yes. Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. This is semi-correct. Which means that it's correct unless you're very careful when you design it. But we're being careful, aren't we? Again, I'll elaborate later on the flexible API I'm thinking of later... Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. It may or may not be. Input devices are not tablets only. Yes, yes! A hierachy! OK! :-) Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS or XI_ERASER? We might expand the _XDeviceInfo struct to contain information about grouping if that's desired.
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
UPOZORNENI!
Dekujeme za odeslani zpravy na adresu [EMAIL PROTECTED] Tato adresa je vyhrazena pro pouziti v dokumentaci a obsah prichozich zprav proto neni sledovan. Prijemny den, Spravce domeny priklad.cz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 28 Aug 2003, Marc Aurele La France wrote: It occurs to me that we should probably change XAA to flush CPU caches just after calling the driver's Sync() function, and change mibank to do the same after telling the driver to switch banks. That is a hardware issue and something the driver's Sync() function should be doing, not core code. The nv driver already does that. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote: Secondly, EFI is already doing the wrong thing by marking PCI ROMs as non-cacheable. This doesn't inspire confidence... I believe there is a difference between ROM's being logically cacheable and the way the ZX1 actually wires that memory into the memory system. The ZX1 connection to PCI devices are always non-cached. It's a simplified assumption correct in most all cases with little penalty for the rare case of cacheable memory sitting out in MMIO space. Therefore EFI is not doing the wrong thing by marking ROM as non-cacheable, the ZX1 is going to treat any PCI address as non-cached by design. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
Michel Dänzer wrote: Text drawing (x11perf -aa24text) went from 25000 to 105000, which is more than factor 4. I am satisfied. Err, I get without acceleration on a 1 Ghz TiBook: 960 reps @ 0.0006 msec (154.0/sec): Char in 30-char aa line (Charter 24) That is in hardware or not really antialiased. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 28 Aug 2003, Mark Vojkovich wrote: It occurs to me that we should probably change XAA to flush CPU caches just after calling the driver's Sync() function, and change mibank to do the same after telling the driver to switch banks. That is a hardware issue and something the driver's Sync() function should be doing, not core code. The nv driver already does that. The driver has no business dealing with architecture concerns. When it does/must, it's an indication the common layer, or common module, is not doing its job. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
New device handling in X (was: XInput: The device type inXListInputDevices comes up again...)
This is a summation of the discussion between the est. Bryan W. Headley, the est. Egbert Eich and myself so far, along with a few new ideas... OK. Most people seem to think we need a new way to do device handling of what is currently called extended devices in X. I, as an applications programmer, find that it is far too restrictive and very importantly that the device drivers written for it do not sufficiently conform to the documentation, and the device programmers find that it cannot express all the aspects of a modern Human Input Device (or HID). There are two choices: Either to fix the old broken API or to make something new and phase the old API out. In favor of fixing the old API is the fact that making a new one would mean going over every driver to make them conform to the new API. This is a large task. Besides, people know the old API. In favor of making a new API and phasing the old one out are: a) We can do it much better without being inhibited by any choices that were made in the old one. b) Because it's a new API it's easier to enforce the standard rigidly so we don't get all that I'm putting something different in the -type and -name field than you-nightmare all over again. c) People might know the old API but it's not exactly loved... d) If we expand the old API, we probably still need to go over most drivers. As you might gather, I'm all for making a new API. --- If the situation looks like this: Applications -- XInput API -- Device drivers -- Kernel then there's no denying that my experience lies mostly in the two upper parts. I also understand that Bryan is mostly down in the two lower parts, occasionally sticking his head all the way up to Applications level (correct me if I'm wrong, that's just the impression I got from the correspondence). Since it's the primarily the API that's ineffective, I suggest starting from there - that's also what we all know something about. Summing up on the discussion so far, we want an API with: a) Hierarchial ordering of devices. b) Hot-pluggability. c) An extremely flexible interface for letting the application know what the device is telling us. d) The possibility to have communication back and forth between device(driver) and application. I propose that we simply start by defining the new API as a header file (or set of header files). The first version might not look anything like the finished result but we'll have something constructive to work from and a common reference. I would be happy to make a suggestion which I will hasten to say would *not* be my idea of how it should be but rather some loose sketches on what it might be which we can then add to and change as befits us. How does this sound? --- And now for the rambling brain-storm part of the mail: As regards the flexible interface, I was thinking... Practically all devices actually send rather kinds similar information. I'm not sure what a dataglove sends but a mouse basically sends a point and so do tablets as far as I know - of course they're respectively relative and absolute coordinates, but still. Joysticks actually send a 2d-vector (which is [0, 0] when it's not touched), spaceballs send a 3d-vector... All of them neat physical concepts. Was it possible that upon opening the device, you could be told: When I'm sending you an event, it's going to be so-and-so long. There will be x longs (or reals or whatever) of information, of which the first two will be an absolute position, the next two will be button states, etc. etc. A dataglove might send 20 or something 3d-points with every event, one for each point on the glove. I know this is crude but it is just to let you understand the general idea. After all, the physical devices are real-world objects; what they put into the computer is real-world information. If you can interpret 2d- and 3d points and vectors and radians, what other kinds of measurement are there, physically speaking? If we could only structure the information in some way so that it's easier for the application to understand... The hierarchial structure might, in fact, help. Consider the dataglove again. We could register the glove with each finder as a subdevice which each measurement point along the finger as a subdevice again. Suddenly, the structure of the information makes it much easier for the application to understand the data... Does this make any sense? Looking forward to your input, /Claus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
On Thu, 28 Aug 2003, Thomas Winischhofer wrote: Michel Dänzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Yours is unusually fast. You must have AGP fastwrites on. Why the h*ck is render so fast on your machine? That was hardware accelerated, or not really antialiased. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RENDER question
Mark Vojkovich wrote: On Thu, 28 Aug 2003, Thomas Winischhofer wrote: Michel Dänzer wrote: [stripped] ( 3180.0/sec): 500x500 rectangle ( 1920.0/sec): 500x500 tiled rectangle (17x15 tile) ( 139.0/sec): ShmPutImage 500x500 square Here (P4 Celeron, 2.0Ghz, SiSM650, DDR266) it's 2500/sec for rect500 1100/sec for oddtilerect500 717/sec for shmput500 Seems your engine is a bit faster (rect500, oddtilerect). VideoRAM access seems slower, though ?! Huh? Yours is unusually fast. You must have AGP fastwrites on. What value are you referring to? Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 28 Aug 2003, Marc Aurele La France wrote: On 28 Aug 2003, John Dennis wrote: On Thu, 2003-08-28 at 12:46, Marc Aurele La France wrote: Secondly, EFI is already doing the wrong thing by marking PCI ROMs as non-cacheable. This doesn't inspire confidence... I believe there is a difference between ROM's being logically cacheable and the way the ZX1 actually wires that memory into the memory system. The ZX1 connection to PCI devices are always non-cached. It's a simplified assumption correct in most all cases with little penalty for the rare case of cacheable memory sitting out in MMIO space. Therefore EFI is not doing the wrong thing by marking ROM as non-cacheable, the ZX1 is going to treat any PCI address as non-cached by design. ... which basically means that framebuffers cannot benifit from CPU caching. I don't beleive this to be the case. Further to this, it appears you don't realise that the frambuffers we're talking about here, _are_ in PCI space. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 28 Aug 2003, Marc Aurele La France wrote: On Thu, 28 Aug 2003, Mark Vojkovich wrote: It occurs to me that we should probably change XAA to flush CPU caches just after calling the driver's Sync() function, and change mibank to do the same after telling the driver to switch banks. That is a hardware issue and something the driver's Sync() function should be doing, not core code. The nv driver already does that. The driver has no business dealing with architecture concerns. When it You've got to be kidding. It must deal with architecture concerns when it's writing registers and such. does/must, it's an indication the common layer, or common module, is not doing its job. By flushing CPU caches you mean a fence? The driver has to do that anyway to ensure that it actually Syncs the hardware. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: *** xf86BiosREAD, IA64, Multi-card Init ***
On Thu, 2003-08-28 at 16:40, Marc Aurele La France wrote: ... which basically means that framebuffers cannot benifit from CPU caching. I don't beleive this to be the case. Further to this, it appears you don't realise that the frambuffers we're talking about here, _are_ in PCI space. Yes, I realize framebuffers are in PCI space. All I can do is make the following observations: 1) I was told by HP: The ZX1 chipset doesn't support cacheable access to any MMIO space, regardless of whether that space happens to contain RAM, ROM, device CSRs, etc. This statement seems clear to me, do you have a different interpretation? 2) Write combining is a typical memory attribute to apply to a framebuffer, on the IA64 the write combining memory attribute is also non-cacheable. 3) Would you really want caching on framebuffer memory in the presence of a graphics co-processor that can alter the memory independently of the cache? 4) It does not seem outlandish when considering the universe of PCI devices to believe the memory regions on these devices either have side-effects or can be modified by the device, either case would demand non-caching. It would be very hard, as it has been pointed out, for the firmware to know what memory regions on a device could be cached safely. Thus a decision to treat any PCI memory region as non-cached sounds like a plausible design decision. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
xfree86, DRI, and multiple heads: thoughts and ideas
Dualhead... Right now there is dualhead support for the following cards in xfree86: radeon matrox sis via chips 3dlabs (Sven mentioned that he had this quasi-working on the newer cards, although I don't know the state of his driver) The following cards have hw dualhead support, but no driver support for it: i830/845 mach64 rage128 savage trident smi I don't suppose there is much interest in adding dualhead support for these cards. Is there anything in the pipeline? I've studied the other dualhead drivers pretty extensively, and I think I could provide a generic dualhead capable skeleton driver and a howto document. Would anyone find this to be a benefit? perhaps to be included in xfree for future driver writers? Are databooks for any of these cards readily available anywhere? I might be willing to try my hand at this again if I could get databooks. Next, mergedfb... I've been thinking about creating generic xfree support functions to replace the chipset specific ones for mergedfb. This would make it easier to add mergedfb to other chipsets that support dualhead. Where should this live? also, as far as pseudo-xinerama, should that be made part of the generic mergedfb code or part of xinerama proper? i.e., to extend xinerama to handle both multi-card and single card xinerama. Or is all of this going to be refactored in xfree 5? multihead and DRI... There's been some recent work in the DRI tree to track GLX extension state per screen (http://marc.theaimsgroup.com/?l=dri-patchesm=106123210307564w=2). What other things need to happen to get the DRI working on multiple graphics cards? On a related note, I've been thinking about alternative ways to implement mergedfb on radeon hardware. what if instead of creating a single framebuffer with two viewports, we stuck with the old style pScrn based multi-head code, but made each head a client of the DRI? the 3D engine would be shared by each head. This seems to be the way the 2D engine works in pScrn based multi-head now. I can see this working ok for independant heads, but what about when using xinerama? what would need to be done in that case? perhaps glxproxy from dmx (dmx.sf.net) would be of use in this case. would doing this potentially get around the issues with the scissor registers limiting us to 2048x2048 for 3D? I could see potential issues with 3D windows that spanned heads since they would be trading access to the hardware back and forth. Thanks, Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfree86, DRI, and multiple heads: thoughts and ideas
On Thu, Aug 28, 2003 at 07:31:08AM -0700, Alex Deucher wrote: Dualhead... Right now there is dualhead support for the following cards in xfree86: radeon matrox sis via chips 3dlabs (Sven mentioned that he had this quasi-working on the newer cards, although I don't know the state of his driver) Well, the driver is blocked in no-accel state for the wildcat VP 560, this would be no problem for implenting the dual head thing in a merged fb. I have not been doing much work on it lately, and there are still some Issues with dual head when one head is DVI connected. My current XFree86 work has to do with the SDK, but i had not had as much time as i wanted for this too. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Fonts] TAYLOR
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] TAYLOR
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[I18n] Compose files.
Hello, There are some issues related to a symbols composing and Compose files that were mentioned here (and in Bugzilla) during last monthes. The choice of Compose file depends on the current locale and is very unflexible. The files are placed far from other keyboard-related files (many people even can't find them). There is not any way to customize them (e.g. per-user compose file). I'd like to offer some changes in that mechanism that solve at least a part of problems. First of all I should remind that whereas in many systems a composing mechanism (dealing with dead_keys and/or Mylti_key like prefix) is a part of keyboard driver and composing rules are a part of keyboard maps, in X Window it has no relations to XKB and its files. Moreover that composing should work if Xserver and/or Xlib are built without XKB. The most unpleasant consequence is that Xlib use different ways to get Compose files and other keyboard-related data. A keyboard map is kept on a server and Xlib retrives it using XKB protocol (or some core protocol requests) but Compose file is always read localy from client machine filesystem. An ideal solution would be to integrate compose rules into XKB (or core protocols) maps but it needs changes in the protocol or a making new extension. My proposals touch existent files (and compose subsytem) only. Locale independence. In existent files a compose rule consists of two parts. A 'left side' part is a sequence of keysym and a right part (the result of composing) is a pair of a mylti_byte string and a keysym. Both members ot that pair are independed. Each of them can be omited and the compose subsystem doesn't check any matching between them and doesn't figure out any one of them from other. On the one hand it provides a flexibility. The multy_byte string may have no corrsponded keysym and even be some arbitrary string (a word or even a sentence). On the other hand it causes problem when user changes a locale. The string there is exactly what XmbLookupString has to return (without any changes). Hence for non-ASCII symbols it should be different for C and UTF-8 locales. (Hans Deragon wrote here about the problem he faced: when he changed a locale to Unicode one, some sequences appeared changed because Xlib used another Compose file.) It can be fixed easy. If the result of a compose rule ia a keysym only Xlib has to convert it to a string according to the current locale in the way used for usual key press/release events. It this case one compose files can be used for different locales and depends on a keybord map only. Customization. I added to Compose file an 'include' instriction. It allows to compose Compose file :-) from some files and add small corrections that user prefers. E.g. if user has custom Compose file it can look like include system wide file my_own_rules ... Of course, if some rules overlap, Xlib just discards a previous rule and uses latest one. Also I think some substitutions in the included file name could be usefull. A made two ones: %H means the value of HOME variable and %L means the name with full path to a currently used local-depended file (e.g /usr/X11R6/lib/X11/locale/iso8859-1/Compose). The first substitution woild allow to add a per-user preference file into a 'system' Compose file, e.g. system-wide file: common_rules ... include %H/.XCompose If the file doesn't exist Xlib silently ignores such instruction. The second substitution would allow user to add currently used files into own custom Compose file without care where that file is actually placed. In finally a most doubtfull part: how to specify needed Compose file. Now I made an environment variable XCOMPOSEFILE which value should be a name (with a path) of Compose file. But I realize it is unhandly for users. Any ideas are welcome. P.S. All changes I'm talking about are already made and tested. I can commit them in any time. But I'd like to hear suggestions/objections. -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
RE: [I18n] Compose files.
Ivan Pascal wrote:
The choice of Compose file depends on the current locale and
is very unflexible.
The files are placed far from other keyboard-related files
(many people even
can't find them). There is not any way to customize them
(e.g. per-user
compose file).
I'd like to offer some changes in that mechanism that solve
at least a part of problems.
First of all I should remind that whereas in many systems a
composing mechanism
(dealing with dead_keys and/or Mylti_key like prefix) is a
part of keyboard
driver and composing rules are a part of keyboard maps,
Yes, indeed. And that is where they logically belong. It should
be made this way also for XKB.
...
An ideal solution would be to integrate compose rules into
XKB (or core
Yes, please.
protocols) maps but it needs changes in the protocol or a
making new extension.
My proposals touch existent files (and compose subsytem) only.
Locale independence.
In existent files a compose rule consists of two parts. A
'left side' part is
a sequence of keysym and a right part (the result of
composing) is a pair of
a mylti_byte string and a keysym. Both members ot that pair
are independed.
Each of them can be omited and the compose subsystem doesn't check any
matching between them and doesn't figure out any one of them
from other.
Ideally, one specifies a sequence(!!) of keysyms that result form
a composition. Each keysym should be translated to text in the
same way a keysym for a plain keystroke is translated to (a)
character(s).
Which compose file (using a more XKB-ish syntax inside) to use
should be specified by the keyboard layout; something like:
default alphanumeric_keys xkb_symbols qwerty-dead_keys
{
// key-keysym allocation here; and then:
compose euro-latin; // (e.g.)
}
/kent k
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [XFree86] Problems with S3 968 Vision
Hi, On: Wed, 27 Aug 2003 18:27:30 -0500 (CDT), Tothwolf [EMAIL PROTECTED] wrote: On Sun, 24 Aug 2003, Rene Rebe wrote: I just got an old IBM PowerPC box with S3 Vision 864 - where even no code is present in 4.3.x to support it ... Your 964 should be support (from what I see in the code), and your XFree also recognize it: (II) S3: driver (version 0.3.5 for S3 chipset: 964-0, 964-1, 968, Trio32/64, Aurora64V+ The problem is that the IBM RGB526 RAMDAC is not supported. All of the 968 based cards I have use that RAMDAC, though there were other RAMDACs that could be used with the 968 too. Yes - I know about this details. My box used an SDAC - but support for the IBM RAMDAC is present. Nevertheless - I just started to port the old code from 3.3.6 for my card (864) to 4.3.99.x. If you port the RGB526 RAMDAC support for the 968, I'd like to test your changes. This should be there (at least 4.3.99.x). I also have some old Western Digital Paradise, and a ET3000 lying arround. And if I'm lucky I should have my first Videocard in my life - a Tseng Labs - lying somewhere. If I find free time I could port those bits, too. I really would like to see all the old cards supported - maybe someone wants to sponsor me to port the code? I too have some of these cards, and many, many more. I have a fairly large collection of old cards, but I don't have any programming docs for their chip sets. If you know C and have some spare time this should be possible to just port the old drivers. But the S3 is a rahter complex one with all this RAMDACs and IMHO higly spaghetti coded :-( I spent nearly a full work-day to port the SDAC GENDAC code - and I'm not yet finished. But this is postponed until I have more free time - or a sponsor (I currently can not afford investing a whole week or so to port this). (Note, I didn't CC: this to the mailing list, though it might be on-topic.) I CC it again ;-) -Toth Sincerely yours, René Rebe - ROCK Linux stable release maintainer -- René Rebe - Europe/Germany/Berlin [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.rocklinux.org http://www.rocklinux.net/people/rene http://gsmp.tfh-berlin.de/gsmp http://gsmp.tfh-berlin.de/rene ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] extract (gnu-tar) segfaults on debian SID
On Tue, Aug 26, 2003 at 11:30:57AM +0200, Egbert Eich wrote: David Dawes writes: On Tue, Aug 26, 2003 at 02:24:23AM +0200, wim delvaux wrote: It happens when installing 4.3.0 with Xinstall.bin MD5 sums seems to be identical Does anybody know why or have the same experience ? We occasionally see reports like this, but I don't recall if the reason for the problem was found. The extract binary for Linux is statically linked. Maybe we need dynamically linked versions? Yes, I think that's the problem. Statically linked libc's are not really static any more as they pull in shared modules. This seems to be causing trouble. I can build a glibc22-based dynamically linked version (don't have any glibc23 systems here at the moment) and put that up for both the glibc22 and glibc23 bindists if that would help. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] extract (gnu-tar) segfaults on debian SID
On Thursday 28 August 2003 03:53, David Dawes wrote: On Tue, Aug 26, 2003 at 11:30:57AM +0200, Egbert Eich wrote: David Dawes writes: On Tue, Aug 26, 2003 at 02:24:23AM +0200, wim delvaux wrote: It happens when installing 4.3.0 with Xinstall.bin MD5 sums seems to be identical Does anybody know why or have the same experience ? We occasionally see reports like this, but I don't recall if the reason for the problem was found. The extract binary for Linux is statically linked. Maybe we need dynamically linked versions? Yes, I think that's the problem. Statically linked libc's are not really static any more as they pull in shared modules. This seems to be causing trouble. I can build a glibc22-based dynamically linked version (don't have any glibc23 systems here at the moment) and put that up for both the glibc22 and glibc23 bindists if that would help. I had that problem too and just downloaded the utils in source and compiled the gnu-tar util. W David ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] XFree86 Segmentation Fault (extract problem?)
On Wed, Aug 27, 2003 at 01:32:49PM -0300, L e a n d r o S a l e s wrote: Hi! I'm using Debian woody(unstable version) and I'm trying to install XFree86 4.3. I downloaded Xinstall.sh and run: # sh Xinstall sh -check Checking which OS you're running... uname reports 'Linux' version '2.4.18', architecture 'i686' Object format is 'ELF'. libc version is '6.3.2' (6.3). Binary distribution name is 'Linux-ix86-glibc23' If you don't ... So, I downloaded all http://ftp.xfree86.org/pub/XFree86/4.3.0/binaries/Linux- ix86-glibc23/ files. After this, I did: # sh Xinstall.sh the Xinstall.sh script prompted some questions and asked if I want to continue: Do you wish to continue? (y/n) [n] y Checking which OS you're running... uname reports 'Linux' version '2.4.18', architecture 'i686' Object format is 'ELF'. libc version is '6.3.2' (6.3). Xinstall.sh: line 1050: 1852 Segmentation fault $TAR xzf $VERSTARBALL $VERSIONFILE Warning: can't detect the bindist version ... ... argh!! I don't know what happened! :( I run this same installation other times and everything was successfull. I think that is some problem with extract command. So, if I run, 4 exemple: # chmod +x extract # ./extract Xdoc.tgz (or any other tgz file I got:) == Extracting Xdoc.tgz == Segmentation Fault So, I try to do a shell script with something like this: #!/bin/bash tar zxf $1 I named it 'extract' and did 'chmod +x extract', but it didn't work! :( The Xinstall.sh script said that extract command was bad, rename it to extract.bad and re-create extract file. Does someone can help me? All pointers/suggestions gratefully accepted. Thank you. This is the second report in two days. It seems that the statically linked extract binary isn't as portable as was hoped. I've replaced it with a dynamically linked version. It was built on a glibc22 system (RH 7.2), but it should work on more recent systems. If you still have problems with this one, let us know. If all else fails, you can download the source for extract and build your own. It's in the utils-1.1.0.tgz file in ftp://ftp.xfree86.org/pub/XFree86/4.3.0/source/. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Re: log anexo
Suporte Erect escreveu: Ol pessoal, Aps sair do KDE, o Xserver parou. Obrigado pela ateno, Abraos. XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-0.13mdksmp i686 [ELF] Build Date: 12 March 2003 Before reporting problems, check http://www.XFree86.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/XFree86.0.log", Time: Wed Aug 27 03:23:12 2003 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "layout1" (**) |--Screen "screen1" (0) (**) | |--Monitor "monitor1" (**) | |--Device "device1" (**) |--Input Device "Keyboard1" (WW) Option "XkbCompat" requires an string value (**) Option "XkbModel" "abnt2" (**) XKB: model: "abnt2" (**) Option "XkbLayout" "br" (**) XKB: layout: "br" (WW) Option "XkbOptions" requires an string value (==) Keyboard: CustomKeycode disabled (**) |--Input Device "Mouse1" (**) FontPath set to "unix/:-1" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (**) Option "AllowMouseOpenFail" Using vt 7 (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 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="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1039,0745 card 1043,8083 rev 01 class 06,00,00 hdr 80 (II) PCI: 00:01:0: chip 1039,0001 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 1039,0018 card , rev 00 class 06,01,00 hdr 80 (II) PCI: 00:02:2: chip 1039,7001 card 1043,8083 rev 07 class 0c,03,10 hdr 00 (II) PCI: 00:02:3: chip 1039,7001 card 1043,8083 rev 07 class 0c,03,10 hdr 00 (II) PCI: 00:02:5: chip 1039,5513 card 1043,8083 rev d0 class 01,01,80 hdr 80 (II) PCI: 00:05:0: chip 13f6,0111 card 1043,80e2 rev 10 class 04,01,00 hdr 00 (II) PCI: 00:08:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:0a:0: chip 10ec,8139 card 10ec,8139 rev 10 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 10de,002d card , rev 15 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 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xf300 - 0xf3ff (0x100) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xfbf0 - 0xfebf (0x2d0) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:2:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI:*(1:0:0) nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] rev 21, Mem @ 0xf300/24, 0xfc00/25, BIOS @ 0xfbff/16 (II) Addressable bus resource ranges are [0] -1 0 0x - 0x (0x0) MX[B] [1] -1 0 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0 0x000f - 0x000f (0x1) MX[B] [3] -1 0 0x000c - 0x000e (0x3) MX[B] [4] -1 0 0x - 0x0009 (0xa) MX[B] [5] -1 0 0x - 0x (0x1) IX[B] [6] -1 0 0x - 0x00ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xf400 from 0xf7ff to 0xf3ff (II) Active PCI resource ranges: [0] -1 0 0xf100 - 0xf1ff (0x100) MX[B] [1] -1 0 0xf180 - 0xf18000ff (0x100) MX[B] [2] -1 0 0xf200 - 0xf2000fff (0x1000) MX[B] [3] -1 0 0xf280 - 0xf2800fff (0x1000) MX[B] [4] -1 0 0xf400 - 0xf3ff (0x0) MX[B]O [5] -1 0 0xfbff - 0xfbff (0x1) MX[B](B) [6] -1 0 0xfc00 - 0xfdff (0x200) MX[B](B) [7] -1 0 0xf300 - 0xf3ff (0x100)
[XFree86] Find Fake Event
Hello All, How to differentiate the Fake Event from Normal Event ? TIA, -- Bharathi S, IndLinuX Team, (__) DON Lab,TeNeT Group, oo ) IIT-Madras, Chennai-INDIA. (_/\ Known is DROP, Unknown is OCEAN. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] troubleshooting XFree86 problem
Dear Sir / Madam, Dated: 28th August 2003 I have installed RedHat Linux Server 7.1 (SeaWolf) configured as Squid Caching Proxy Internet Server. My problems are : 1. During normal bootup the system always enters a checkforce mode. I have tried to debug this problem by entering Single User mode and running fsck.ext2 for filesystem checking. No errors were reported after completion of fsck.ext2 2. The KDE Desktop Manager is not running. The GNOME desktop runs but the GUI interface does not appear. Kindly send replies to : [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] console mode problem
Hi I have a problrem working in console mode, after i go into console mode from x-windows mode, i get logged out automatically, and i get the x-window login screen, also i loose all my unsaved work. i have also sent the copy of my XF86Config file, please have a look - # File generated by anaconda. Section ServerLayout Identifier Anaconda Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceMouse1 SendCoreEvents InputDeviceKeyboard0 CoreKeyboard EndSection Section Files # 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 dri Load glx Load record Load freetype Load type1 EndSection Section InputDevice # Option AutoRepeat500 5 # when using XQUEUE, comment out the above line, and uncomment the # following line # Option Protocol Xqueue # 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 XkbVariantnodeadkeys # # If you'd like to switch the positions of your capslock and # control keys, use: # Option XkbOptionsctrl:swapcaps #Option XkbOptions Identifier Keyboard0 Driver keyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout us#Option XkbVariant EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol IMPS/2 Option Device /dev/psaux Option ZAxisMapping 4 5 Option Emulate3Buttons no EndSection Section InputDevice Identifier Mouse1 Driver mouse Option Device /dev/input/mice Option Protocol IMPS/2 Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model HorizSync30.0 - 71.0 VertRefresh 50.0 - 160.0 Option dpms EndSection Section Device # no known options #BusID Identifier VESA driver (generic) Driver vesa VendorName VESA driver (generic) BoardName VESA driver (generic) EndSection Section Screen Identifier Screen0 Device VESA driver (generic) MonitorMonitor0 DefaultDepth 16 SubSection Display Depth 16 Modes1280x1024 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection EndSection Section DRI Mode 0666 EndSection -- Ramakrishna [EMAIL PROTECTED] -- http://www.fastmail.fm - The way an email service should be ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Laptop w/ Radeon 7500 problems
Title: Meddelande I used to work around a problem i had with a distorted screen in X with Option "CrtScreen" on my laptop, but now in recent versions (running debian unstable) it seems that this option has been deprecated. Is there a new "real" fix coming instead of CrtScreen? Thanks in advance Magnus Vage
[XFree86] TAYLOR
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] nVIDIA problem?
Hi there my name is Viktor Soderqvist My problem here is most probably related to nVIDIAs drivers, but I thought I would report it to you anyway; what happens (or happened) is: I installed linux (Mandrake 9.1, KDE as window manager) - Installed nVIDIAs newest drivers - started X, everything worked fine - rebooted a few times and everything is still working fine ... Then just one day: XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.21-0.13mdksmp i686 [ELF] Build Date: 12 March 2003 Before reporting problems, check http://www.XFree86.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/XFree86.0.log, Time: Thu Aug 28 14:37:35 2003 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout layout1 (**) |--Screen screen1 (0) (**) | |--Monitor monitor1 (**) | |--Device device1 (**) |--Input Device Keyboard1 (WW) Option XkbCompat requires an string value (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout se (**) XKB: layout: se (WW) Option XkbOptions requires an string value (==) Keyboard: CustomKeycode disabled (**) |--Input Device Mouse1 (**) FontPath set to unix/:-1 (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (**) Option AllowMouseOpenFail Using vt 7 (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 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=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3099 card 1106, rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b099 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:09:0: chip 10ec,8139 card 1429,d010 rev 10 class 02,00,00 hdr 00 (II) PCI: 00:11:0: chip 1106,3074 card 1106, rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:2: chip 1106,3038 card 0925,1234 rev 1b class 0c,03,00 hdr 00 (II) PCI: 00:11:3: chip 1106,3038 card 0925,1234 rev 1b class 0c,03,00 hdr 00 (II) PCI: 00:11:4: chip 1106,3038 card 0925,1234 rev 1b class 0c,03,00 hdr 00 (II) PCI: 00:11:5: chip 1106,3059 card 4005,4710 rev 10 class 04,01,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0171 card , rev a3 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 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (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 0xdde0 - 0xdfef (0x210) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xcdb0 - 0xddcf (0x1020) 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:*(1:0:0) nVidia Corporation NV17 [GeForce4 MX 440] rev 163, Mem @ 0xde00/24, 0xd000/27, 0xddc8/19, BIOS @ 0xdfee/17 (II) Addressable bus resource ranges are [0] -1 0 0x - 0x (0x0) MX[B] [1] -1 0 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0 0x000f - 0x000f (0x1) MX[B] [3] -1 0 0x000c - 0x000e (0x3) MX[B] [4] -1 0 0x - 0x0009 (0xa) MX[B] [5] -1 0 0x - 0x (0x1) IX[B] [6] -1 0 0x - 0x00ff (0x100) IX[B] (II)
[XFree86] 9200 Radeon DVI...
Try xfree86 cvs. some oems wire their dacs differently. cvs has code to deal with certain situations. use: Option MonitorLayout tdms, none for a single dvi monitor. glibc 2.2 systems can get cvs binaries here: http://www.xfree86.org/~alanh/ for glibc 2.3 systems you will probably have to build your own driver. you can also try my cvs mergedfb binaires, however, they contain my mergedfb patch. http://www.botchco.com/alex/radeon/mergedfb/cvs/cvs-2003-7-31/final/ Alex -- Hi all. I did search the archives, and found someone with an identical problem, but no resolution (although there did appear to be a suggestion...) As subject - I have a Radeon 9200, which runs XFree86 fine. However, video only comes out of the VGA socket, not the DVI one. The DVI socket works, because the console can be seen in it. If I attempt to run X with the monitor plugged into the DVI, the screen goes blank and it then claims there is no signal, then input signal out of range. The video is coming out of the VGA port at this point though, which I can switch to (usually, when using the DVI, there wouldn't be video coming out of the VGA port, it seems). Quitting X and the VGA port goes videoless again, but video does not return to the DVI. I won't paste full logs unless asked, but there were some lines which seemed relevant to my untrained eye: (II) Primary Device is: PCI 02:00:0 (II) ATI: Candidate Device section ATI Technologies, Inc. Radeon RV280 [Radeon 9200]. (WW) ATI: PCI/AGP Mach64 in slot 2:0:1 could not be detected! (--) Assigning device section with no busID to primary device (WW) RADEON: No matching Device section for instance (BusID PCI:2:0:1) found (--) Chipset ATI Radeon 9200 5961 (AGP) found (this card is sitting in an AGP slot of an nVidia nForce motherboard, which has onboard dual-head capable graphics, but which I'm not attempting to use). I'm trying to drive a flat panel at 1280x1024 (its native resolution), the X version is 4.3 from the Debian experimental respository, kernel is 2.6.0-test2. X works great in analogue, so I'm not desperate for a fix, but if anyone can suggest something I'm willing to spend some time fiddling and testing to get it working. I haven't ever even seen the XFree86 source, but I'm fairly competent at compiling/etc... Any suggestions much appreciated :) Cheers, Alex. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] DONATION FOR THE LORD.
FROM: Margeret hatch. I am the above named person from Kuwait. I am married to Mr. Kazeem Hatch who worked with Kuwait embassy in Ivory Coast for nine years before he died in the year 2001. We were married for eleven years without a child.He died after a brief illness that lasted for only four days.Before his death we were both born again Christians.When my late husband was alive he deposited the sum of $5.6Million (Five Million six hundred thousandU.S. Dollars) with one Global Security Company in Spain. Presently, this money is still with the Security Company.Recently, my Doctor told me that I would not last for the next three months due to cancer problem.Though what disturbs me most is my stroke.Having known my condition I decided to donate this fund to church or better still a christian individual that will utilize this money the way am going to instruct here in. I want a church that will use this fund to fund churches, orphanages,Research centers and widows propagating the word of God and to ensure that the house of God is maintained. The Bible made us to understand that Blessed is the hand that giveth. I took this decision because I dont have any child that will inherit this money and my husband relatives are not Christians and I dont want my husbands hard earned money to be misused by unbelievers. I dont want a situation where this money will be used in an ungodly manner. Hence the reason for taking this bold decision. I am not afraid of death hence I know where i am going. I know that I am going to be in the bossom of the Lord, Exodus 14 VS 14 says that the lord will fight my case and i shall hold my peace. I dont need any telephone communication in this regard because of the presence of my husbands relatives around me always. I dont want them to know about this development. With God all things are possible.As soon as I receive your reply I shall give you the contact of the Global Security Company in Spain. I will also issue you a letter of authority that will empower you as the new beneficiary of this fund.I want you and the church to always pray for me because the lord is my shephard. My happiness is that I lived a life of a worthy Christian.Whoever that wants to serve the Lord must serve him in spirit and truth.Please always be prayerful all through your life. Any delay in your reply will give me room in sourcing for a church or christian individual for this ame purpose. Please assure me that you will act accordingly as I stated there-in. Hoping to hearing from you. Remain blessed in the name of the Lord. Yours in Christ, Mrs Magret Hatch ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Radeon M9 = No screen found
After install Mdk 9.1 or Suse 8.2 , XFree freeze. ( Black screen )I change the drivers in FBDEV , and it's good. But not in radeon , vesa and ati. ( Asus L5800C , Modbility M9 64 Mo DDR 64-Bit ) View my log. Email me to : [EMAIL PROTECTED] XFree86[1].0.log Description: Binary data
Re: [XFree86] extract (gnu-tar) segfaults on debian SID
David Dawes writes: I can build a glibc22-based dynamically linked version (don't have any glibc23 systems here at the moment) and put that up for both the glibc22 and glibc23 bindists if that would help. I think it does. The the newer glibcs should be backward compatible. Egbert. ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Help!!!
Hi, Please see my attached log file...gets as far as the nvidia logo and then flashes that continually. Any help with this would be fantastic. If you need any more info please let me know. XFree86.0.log Best Regards Greg Westland XFree86.0.log Description: XFree86.0.log
[XFree86] TAYLOR
ATTENTION: THE PRESIDENT/CHAIRMAN. CEO/MD First, may I solicit your confidentiality in this transaction, this by virtue of its nature. I am Mr Lutherking taylor Jr, a cousin to the president Charles Taylor of Liberia . As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes containing cash of (US$22.5M) he kept in safe custody with a security management company in Spain and it is registered as farmily valiables. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project.Upon receipt of your positive response, I will suggest we meet possible in Spain for us to work out modalities concerning the investment of the money and the ratio you will receive after the collection of the boxes from the security company in Spain. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address( [EMAIL PROTECTED] or [EMAIL PROTECTED]) I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Tel: +34-680-902-518 Best Regards Lutherking Taylor Jr ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Find Fake Event
Hi! You can fake events in (at least) two ways in X. One way is by using XSendEvent and another is by using the XTest extension. When using XSendEvent you can check in your application if the was sent with this function. Some sample code: XEvent ev; XNextEvent(ev); if (ev.xkey.send_event==1) printf (hey, stop sending them faked events\n); else printf (hey, this doesn't seem to be faked\n); When, on the other hand, using XTestFakeMotionEvent (to fake a motion event) I don't know of any way to check if it was faked using XTest extension. regards, hesa On Thu, 2003-08-28 at 08:04, Bharathi S wrote: Hello All, How to differentiate the Fake Event from Normal Event ? TIA, ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Laptop w/ Radeon 7500 problems
In CVS, there is now an option called MonitorLayout that encompasses this functionality. from the radeon man page: Option MonitorLayout string This option is used to overwrite the detected monitor types. This is only required when driver makes a false detection. The possible monitor types are: NONE -- Not connected CRT -- Analog CRT monitor TMDS -- Desktop flat panel LVDS -- Lapto flat panel This option can be used in following format: Option MonitorLayout [type on primary], [type on secondary] For example, Option MonitorLayout CRT, TMDS Primary/Secondary head for dual-head cards: (when only one port is used, it will be treated as the primary regardless) Primary head: DVI port on DVI+VGA cards LCD output on laptops Internal TMDS prot on DVI+DVI cards Secondary head: VGA port on DVI+VGA cards VGA port on laptops External TMDS port on DVI+DVI cards The default value is undefined. Alex --- I used to work around a problem i had with a distorted screen in X with Option CrtScreen on my laptop, but now in recent versions (running debian unstable) it seems that this option has been deprecated. Is there a new real fix coming instead of CrtScreen? Thanks in advance Magnus Vage __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] problem
Hello, I can no longer run startx after upgrading my Kernal. THanks, jim XFree86 Version 4.3.0 (Red Hat Linux release: 4.3.0-2) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-3bigmem i686 [ELF] Build Date: 27 February 2003 Build Host: porky.devel.redhat.com Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.4.20-20.9 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Mon Aug 18 11:45:58 EDT 2003 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/XFree86.0.log, Time: Thu Aug 28 17:01:30 2003 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Default Layout (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Videocard0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) |--Input Device DevInputMice (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 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=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card , rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 8086,4541 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:2: chip 8086,2487 card 8086,4541 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 8086,4541 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1013,5959 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 14f1,5421 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 10de,0174 card 1028,00d4 rev a3 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 10b7,9200 card 1028,00d4 rev 78 class 02,00,00 hdr 00 (II) PCI: 02:01:0: chip 104c,ac42 card 4000, rev 00 class 06,07,00 hdr 82 (II) PCI: 02:01:1: chip 104c,ac42 card 4800, rev 00 class 06,07,00 hdr 82 (II) PCI: 02:01:2: chip 104c,8027 card 1028,00d4 rev 00 class 0c,00,10 hdr 80 (II) PCI: 02:03:0: chip 14e4,4301 card 1028,0407 rev 02 class 02,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,7), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000e (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xc000 - 0xc0ff (0x100) IX[B] [1] -1 0 0xc400 - 0xc4ff (0x100) IX[B] [2] -1 0 0xc800 - 0xc8ff (0x100) IX[B] [3] -1 0 0xcc00 - 0xccff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xfc00 - 0xfdff (0x200) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xd800 - 0xe7ff (0x1000) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:30:0), (0,2,16), BCTRL: 0x0006 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0 0xe000 - 0xe0ff (0x100) IX[B] [1] -1 0 0xe400 - 0xe4ff (0x100) IX[B] [2] -1 0 0xe800 - 0xe8ff (0x100) IX[B] [3] -1 0 0xec00 - 0xecff (0x100) IX[B]
[XFree86] sending ctl-alt-del to the window manager
Hello, how can one send the key sequence ctl-alt-del to the window manager? -Hanspeter ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Dualhead NVidia GeForce 2 MX RedHat 7.3
Hi, I have been reading through this mailing list, but still can't figure out why my dual monitor set-up won't work. After bootup I only have one monitor working. Any help is very much appreciated. I have two of the same kind of monitor. I'm attaching my /etc/X11/XF86Config file with some cuts I hope are not relevant to my case. Thanks in advance. Balazs Section Files RgbPath /usr/X11R6/lib/X11/rgb FontPath unix/:7100 EndSection Section ServerFlags EndSection Section Monitor Identifier Dell D1626HT_0 VendorName Unknown ModelName Unknown HorizSync 31.0-107.0 VertRefresh 50.0-160.0 ## Modeline definitions omited EndSection Section Monitor Identifier Dell D1626HT_1 VendorName Unknown ModelName Unknown HorizSync 31.0-107.0 VertRefresh 50.0-160.0 EndSection Section Device IdentifierGeneric VGA VendorNameUnknown BoardName Unknown Chipset generic EndSection Section Device Identifier NVIDIA GeForce 2 GTS (generic)_0 VendorName Unknown BoardName Unknown Screen 0 EndSection Section Device Identifier NVIDIA GeForce 2 GTS (generic)_1 VendorName Unknown BoardName Unknown Screen 1 EndSection Section Screen Driver svga Device Generic VGA #Device NVIDIA GeForce 2 GTS (generic) Monitor Dell D1626HT_0 Subsection Display Depth 8 #Modes (null) ViewPort0 0 EndSubsection EndSection Section Screen Driver vga16 Device Generic VGA Monitor Dell D1626HT_0 Subsection Display Modes 640x480 800x600 ViewPort0 0 EndSubsection EndSection Section Screen Driver vga2 Device Generic VGA Monitor Dell D1626HT_0 Subsection Display Modes 640x480 800x600 ViewPort0 0 EndSubsection EndSection # The accelerated servers Section Screen Identifier Screen0 Driver accel Device NVIDIA GeForce 2 GTS (generic)_0 Monitor Dell D1626HT_0 DefaultColorDepth 32 Subsection Display Depth 24 Modes 1280x1024 EndSubsection Subsection Display Depth 32 Modes 1280x1024 ViewPort0 0 EndSubsection EndSection Section Screen Identifier Screen1 Driver accel Device NVIDIA GeForce 2 GTS (generic)_1 Monitor Dell D1626HT_1 DefaultColorDepth 32 Subsection Display Depth 24 Modes 1280x1024 EndSubsection Subsection Display Depth 32 Modes 1280x1024 ViewPort0 0 EndSubsection EndSection Section ServerLayout Identifier DualHead Screen 0 Screen0 LeftOf Screen1 Screen 1 Screen1 #Option Xinerama InputDevice Mouse0 CorePointer InputDevice Keyboard0 CoreKeyboard EndSection ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] ML9.1: Why difference between screen position of ML8.2 and ML9.1 with same settings in xvidtune -show ?
I have two linux OSes on my computer: ML8.2 and ML9.1. I notice that the screen position of [EMAIL PROTECTED] is different although xvidtune -show show the same settings and the same monitor has been choosen in Monitor setup (I don't have a modeline in XF86Config-4, it's just one automatically made by X with the DDC Monitor info). In ML9.1 (XFree4.3) the screen is horizontally a bit too large such that maximal opened windows loose part of their sides. I can correct this in ML9.1 by using xvidtune but I don't like changing the default modeline and if I use the On Screen Display of my monitor to adjust the screen ML8.2 (XFree4.2) looks too small. Why don't the screens of ML8.2 and ML9.1 use the same monitor space as the settings as shown in xvidtune -show are the same? What other parameters play a role in here and is it possible to set the screens exactly the same? Thank you, vatbier ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
