xfs install on RedHat machine
I have installed the minimal set of packages with RedHat 9.0 and have installed XFree86 xfs later using rpm. XFS is not running after reboot while it is in init.d and rc.d[12345]. Anyone know what causes this behaviour. Regards, Marcel Stegehuis ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
Sven Luther [EMAIL PROTECTED] writes: I've been trying to find specs for implementing hardware RENDER support for my graphics card. I have the specs for the card. The problem is that nobody seems to know what the various RENDER functions in a driver are supposed to do, or what the structs represent. Without this information, there's not much I can do. For a start, look at the mga or the sis driver. Both accelerate aa texture blitting for aa text with quite remarkable speed improvements. I was hoping not to have to wade through hundreds of lines of chip specific code and try to guess what they tell the chip to do. If I only knew exactly what the functions are supposed to do, and what the supplied data is, it would be straight-forward to have my chip do the work. The parts that do RENDER accleration are by no means hundreds lines of code. It plain two accelerator functions. I myself had no clue either when I started, and implementing this took only one day. Then why has not someone added documentation for it in the XAA.HOWTO file, if it is that simple ? Good question. BTW, Sven. RENDER support for Permedia3 should be possible, right? -- Måns Rullgård [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
On Wed, 15 Oct 2003, Alexander Shopov wrote: Quite frankly... random uninformed people making claims that X is slow, without any shred of a clue or properly deduced scientifically measured and reproduceable instrumented data, will always be out there. We can't stop people from spreading unfounded rumours nor from making random guesses as to why they or someone they know may be experiencing slowdowns in some application or another. Actually we can. Make a good demonstration, so that people see that the sentence X is slow is obviously and without any doubt flawed. That doesn't prove anything really. What would it be doing exactly? Blitting rectangles? Drawing lines? Or would it be rendering AA text using the RENDER extension? If something is indeed slow, is it slow because of flaws in the design of X11 itself? Or because of flaws in XFree86's design? Or is it slow because of the XFree86 implementation of X11 has flaws? Or is it only because of certain features missing from the X server and/or video drivers, but not actually an X11 design flaw at all? While people like answers like it is slow or it is fast, as much as people want answers like that, the real answers are much more detailed. The _only_ answer that matters is the technical/scientific one. End users opinions about how things work, and what is fast or slow, and what is at fault if something is slow don't really matter. We, as developers care about _real_ world problems. If something is really slow, before anything can be done about it, someone needs to scientifically analyze the problem and put some numbers behind it. One such problem is the lack of RENDER acceleration in the video drivers. That is not an X11 bug or flaw in any way. It is simply a feature that hasn't been implemented yet for the most part. I don't think trying to prove anything to people who will believe whatever they want to believe helps us any at all personally... I think it helps us prevent the stupid rumor propagating. A vaccine will not heal people, but it will prevent a disease from spreading. It doesn't help anything. People will create rumours and spread them _always_ by the rules of human nature and the fact that the overwhelming majority of people don't understand deep technical issues in general. Also, crappy news sites like Slashdot tend to help spread rumours to the point where it is impossible to counteract the crap, and one's time as a developer is best spent ignoring the ignorant uninformed fools out there, and just going ahead and implementing new features/enhancements/optimizations, and getting real work done. The best thing any of us can do, is continue to properly and scientifically analyze the X server, it's video drivers, and other related technologies, profile them, optimize them, etc. From a development perspective - yes, you are right. Popularization needs a more pro-active approach. Popularization is a natural selection thing. People use what works for them, or what seems to work best for them, or in some cases what works good enough. Advocacy isn't a bad thing of course, but one needs to be careful to not cross the road from advocacy to preaching, and one always must be truely looking at what is best for the particular problem at hand, not just how to further their advocacy, perhaps even at the expense of recommending an inadequate solution to someone for their particular problem. Video gaming is a perfect example. Playing video games is indeed possible in Linux using XFree86. I would NOT advocate Linux/XFree86 to video gamers however, nor would I try to extoll the virtues of gaming in Linux with XFree86. It does work, but it is not a push and click painless experience yet for the masses out there. It fits into the good enough for some people category at best. Gaming isn't a strong point in favour of Linux/XFree86 basically, so it is a bad point to use in advocation. Right now, the biggest hit on the desktop is probably unaccelerated RENDER operations. That's what most users likely see as desktop slowdowns currently. Over time, those things will improve as people write support. I know that, and people on the list know that. However I find it difficult to explain it to people that do not know what RENDER is, people that do not want to know what RENDER is, and people that just trust the old saying: seeing is believing Best regards: al_shopov Sure, nobody said explaining these things is easy of course. Why bother explaining to people in the first place though? Their rumours/opinions/whatever don't really matter much to the technical/scientific/developmental side of things. It's not like all developers are going to be pressured to rewrite an in-kernel X server just because a Slashdot crowd of end users appears with white masks on and demands it. The technical OSS community in general develops real solutions to solve _real_
Re: xfs install on RedHat machine
On Wed, 15 Oct 2003 [EMAIL PROTECTED] wrote: Date: Wed, 15 Oct 2003 09:10:01 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Subject: xfs install on RedHat machine I have installed the minimal set of packages with RedHat 9.0 and have installed XFree86 xfs later using rpm. XFS is not running after reboot while it is in init.d and rc.d[12345]. Anyone know what causes this behaviour. run ntsysv as root and enable the xfs service. That will make it start at boot time. You can also use service xfs start to start it from the command prompt. If it does not start, look in /var/log/messages and you will find out why it is not starting. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
The _only_ answer that matters is the technical/scientific one. End users opinions about how things Technically and scientifically you are right and I agree with you, but not everyone has the patience for the scientific side. I as sorry as you are about this thing, but some magic some times is surely appreciated. It doesn't help anything. People will create rumours and spread them _always_ by the rules of human nature and the fact that the overwhelming majority of people don't understand deep technical issues in general. Maybe it will not help directly you but it will help me in several ways. I will not have to dispel the myth about the networking in X that slows it down. I will talk about RENDER or sth. else. And maybe people will stop pesting XFree86 developers to drop netwoking support. (Well they are sure to find sth else to unscientifically voice their opinion about, but let us make this one little step) Video gaming is a perfect example. Playing video games is indeed possible in Linux using XFree86. I would NOT advocate Linux/XFree86 to video gamers however, nor would I try to extoll the virtues of gaming in Linux with XFree86. It does work, but it is not a push and click painless experience yet for the masses out there. Actually you ARE dropping several variables from the equation. Real life example - we had recently in Bulgaria the following case: Microsoft told computer gaming clubs that they could not use their bought and paid up licenses for Windows 98 and let people hire the computers on a per hour basis. Microsoft's view was that they needed Windows XP Professional licenses. The clubs showed the letters they had with MS partners from which they bought the licenses in which MS distributors explicitly stated that Windows 98 is the necessary version that would suffice (the letters were written maybe 2 years before Win XP was on the market) What finally happened is that clubs got busted, non-compliance with licences was found (as well as tax avoidance) and a club had more than 200 computers confiscated. So - for the end user perspective - gaming in XFree86 is not painless, but for the point of perspective of game club manager - it is less painful to have to pay your network administrators to make the thing click than to have your machines confiscated. You are sayng that you need to make comparisons with things being equal. You mean - hardware configuration and so on. But there are people for whom what matters is the cost - so hardware specs can be left aside. You can invest what you save from licensing the OS in more games or better hardware. Sure, nobody said explaining these things is easy of course. Why bother explaining to people in the first place though? Their rumours/opinions/whatever don't really matter much to the technical/scientific/developmental side of things. It's not like Well times like when Bruno got burned are a thing of the past but people can get fired for voicing their scientific opinion which is not in line with the great line and path ahead. And as this thread gets way off the limits of the theme of the list, let me ask the quetsions in a very humble way: Will you help me show the magic in XFree86? The jaw dropping side of things? Best regards: al_shopov ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problem with ATI Radeon Mobility M6 LW
On Tue, 2003-10-14 at 10:33, Dimitris S. Economou wrote: Hi all, I have recently bought a Compaq evo N610C laptop and I'm encountering a problem with the graphics card adapter. The display is flickering producing a distortion in the displayed image. While the display is in this destorted shape it is impossible for someone to work with (not even shut down the laptop gracefully). The problem arises through a list of actions listed below: 1. While booting and after switches to a high resolution display taking advantage of the frame buffer. 2. While switching from X display to virtual consoles and vice-versa (ctrl-alt + Fn) 3. When the lid is opened while the laptop is in normal operation. 4. While resuming from standby. [...] I noticed from the change-log of XFree86 4.3.99.14 a related announcement which maybe the solution of the problem and I reiterate the snippet: ... 478. Radeon driver fixes (Hui [EMAIL PROTECTED]) [...] Does indeed solves the reported problem? Possibly. Trying the driver from current CVS certainly isn't a bad idea. -- 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: xfs install on RedHat machine
[EMAIL PROTECTED] wrote: I have installed the minimal set of packages with RedHat 9.0 and have installed XFree86 xfs later using rpm. XFS is not running after reboot while it is in init.d and rc.d[12345]. Anyone know what causes this behaviour. Regards, Marcel Stegehuis I saw a similar problem recently; essentially, the init.d/xfs script was being run, but no xfs got started and there was no clue in the logs about what was failing. Then I realized that my root filesystem was full. After I cleaned up some space and rebooted, everything worked fine. Silly, but true... Chris Burghart ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to render multiple cursors?
--- Kieran O'Sullivan [EMAIL PROTECTED] wrote: Why would you want more than one pointer? and more importantly how would it be used? I wonder if you are not making life more difficult than it needs to be. Actually the more I think about the more I really want to know the answer to thoes two questions. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel Our motivation for having multiple pointers is that we are building large displays (20+ feet) for collaboration. Displays this size may sometimes be used by multiple people simultaneously either on related or unrelated task. So we would like to provide each person with a cursor and the ability to start or migrate applications to the shared display. Initially we just want to support mulitple people working simultaneously on different applications. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to render multiple cursors?
On Thursday 09 October 2003 08:03, Kieran O'Sullivan wrote: Why would you want more than one pointer? and more importantly how would it be used? 1. It's quite conciveable that two cursors could be used to perform two actions at the same time, I mean most of us use multitasking OS'es so the cursors should reflect that. 2. USE YOUR IMAGINATION! Two usb mice, one in your left hand, one in your right. You use one to click and drag a window out of the way and you use the other to choose your favorite song on XMMS. The uses of the technology will expand to fit the technology, that's what OpenSource development is all about. (actually what first is needed is someone with ambition AND coding skills. Like many others, I only have the latter.) I wonder if you are not making life more difficult than it needs to be. How? By proposing an Idea? Actually the more I think about the more I really want to know the answer to thoes two questions. See above :) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xfs install on RedHat machine
On Wed, 15 Oct 2003, Chris Burghart wrote: I saw a similar problem recently; essentially, the init.d/xfs script was being run, but no xfs got started and there was no clue in the logs about what was failing. Then I realized that my root filesystem was full. After I cleaned up some space and rebooted, everything worked fine. Silly, but true... Kindof funny actually... some people have complained that xfs should be updated to log this using syslog, however in the majority of systems out there, /var/log is on the same partition as /tmp usually is - /, and if the disk is full, the disk is full. I seem to recall xfs was updated to do this anyway, but I'd have to do a test setup to confirm it. Not a priority... -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How to render multiple cursors?
On Wed, 15 Oct 2003, david mattatall wrote: Why would you want more than one pointer? and more importantly how would it be used? 1. It's quite conciveable that two cursors could be used to perform two actions at the same time, I mean most of us use multitasking OS'es so the cursors should reflect that. 2. USE YOUR IMAGINATION! Two usb mice, one in your left hand, one in your right. You use one to click and drag a window out of the way and you use the other to choose your favorite song on XMMS. The uses of the technology will expand to fit the technology, that's what OpenSource development is all about. (actually what first is needed is someone with ambition AND coding skills. Like many others, I only have the latter.) I find it rather unlikely that someone would use a mouse in each hand for any real world non-hypothetical because I can sense. Come up with an actual *tangible* reason, and then it's something to discuss IMHO. Open source development isn't all about devising and implementing useless features nobody will use for any useful purpose. I wonder if you are not making life more difficult than it needs to be. How? By proposing an Idea? I see no demand for your idea out there. Actually the more I think about the more I really want to know the answer to thoes two questions. See above :) Feel free to implement it, and then fix all window managers and other affected applications out there, then propose it as an enhancement if you like. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
What is funny however, is that any alternative to X, is more or less functionally useless until someone writes an X server for it for most general purpose computing. Well, it would really only /require/ an xlib-compatable interface, but everybody seems to port XFree86 to run as a client to their window system instead. Presumably it's easier. Benchmarks can be a useful thing to compare computer systems or software with, but benchmarks can also be used intentionally to highlight the best points of the system one wants to win, and highlight the weak points of the other system. Lies, damnn lies, and In short, benchmarks and similar tests are only one thing, and the information they provide is not 100% conclusive all around in a general sense. Benchmarking is a bit like academic tests. It proves that you're good at the benchmark, not at the task. Not sure exactly what you're asking here.. It takes a lot for my jaw to drop though. I'm not sure XFree86, or any other computer software can make that happen though. Ok, maybe the Halflife 2 movie trailer comes close... grin Heh... I found XDMCP to be pretty jaw-dropping when I started using it... Craig Ringer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
VIA's Savage Drivers
Some months ago, VIA released an XFree86 Savage driver in source form that included, among other things, a DRI driver and XvMC support. Has that code been integrated into the XFree86 source tree? Will it make XFree86 4.4? Or is it still waiting in limbo for someone to do the integration? -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: You suggest an upgrade, eh?
CR Benchmarking is a bit like academic tests. It proves that you're good CR at the benchmark, not at the task. You can't cheat at a benchmark. (To be a little bit less cryptical: benchmarks are all we've got to make sure we're making sense in our design and implementation. In the right hands, benchmarks don't lie. But benchmarks are useful for the programmer, who knows what exactly he's measuring. They are not necessarily useful for the user. End of bracket.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Export symbol lists on Linux (was Re: RFC Marking private symbols in XFree86 shared libraries as private)
On Tue, Oct 14, 2003 at 09:50:07PM +0200, Jakub Jelinek wrote: I'd say it would be better to reuse *-def.cpp files (didn't know something like that existed). I've preprocessed all *-def.cpp files included in XFree86/xc/lib, gathered all symbols currently exported from XFree86 shared libraries, all undefined symbols in 5800 shared libraries and binaries I found on my box which are satisfied by one of XFree86 shared libraries and attached are results. The first is a MUST list, symbols which are exported from XFree86 shared libraries now when there is no anonymous version script, are not exported when an anonymous versions script created from stock *-def.cpp file is applied and are used by some binary or shared library (including other shared libraries in the XFree86 collection). There is IMHO no way other than adding these to *-def.cpp files (any issues with this)? There is a good chance that some of these are unintentionally omitted from the -def.cpp files. That's less likely to be a problem as more platforms begin using this data. Checking the MUST list against the API specs is the best way to determine which are unintentional. Hopefully that will result in a much smaller list. That list is interesting from the point of view of reconciling the specs with actual usage. It is also possible that the -def.cpp export some symbols that shouldn't be exported, and that check against the API specs needs to be made too. For libGL.so, as anonymous version scripts accept wildcards, I think we should use gl* wildcard, as it is too error-prone to list all the gl* functions. Will the wildcard method work for the platforms that currently use the -def.cpp lists? The GL and GLX APIs should be well-defined. For libGLU.so, I think we should export everything, no version script on Linux. Second is a MAY list. These are symbols ATM exported from the shared libraries, which would be hidden by linker script but which looked to me like they are in the standard namespace of the libraries and thus might be good candidates for exports. Can anyone please review these and tell me if there are some which definitely shouldn't be exported? They need to be checked against the API specs too. I can supply a tarball with all the symbols ATM exported, exported via *-def.cpp, used etc. to interested parties if you want to do more investigations. I'll follow up with a patch which exports MUST + current *-def.cpp ones and will wait for responses about the MAY list (or candidates not even on MAY list). Jakub -- MUST list -- libGL.so XF86DRIAuthConnection XF86DRICloseConnection XF86DRICloseFullScreen XF86DRICreateContext XF86DRICreateDrawable XF86DRIDestroyContext XF86DRIDestroyDrawable XF86DRIGetClientDriverName XF86DRIGetDeviceInfo XF86DRIGetDrawableInfo XF86DRIOpenConnection XF86DRIOpenFullScreen XF86DRIQueryDirectRenderingCapable XF86DRIQueryVersion All of those are used by the DRI driver modules. I believe there are plans for having those modules use another mechanism for accessing these functions, but they'd still need to be exported for compatibility. Another alternative might be splitting them into a separate shared library that our libGL dlopen's. I don't know if any applications directly access the DRI extension. libXext.so XShmAttach XShmCreateImage XShmCreatePixmap XShmDetach XShmGetEventBase XShmGetImage XShmPixmapFormat XShmPutImage XShmQueryExtension XShmQueryVersion Those definitely get added. -- MAY list -- libX11.so KeySymToUcs4 XkbChangeKeycodeRange Xutf8DrawImageString Xutf8DrawString Xutf8DrawText Xutf8LookupString Xutf8ResetIC Xutf8SetWMProperties Xutf8TextEscapement Xutf8TextExtents Xutf8TextPerCharExtents The Xutf8 functions are part of our extensions to Xlib, so should be exported. Hopefully others can give you some more feedback about the areas they are more familiar with. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Kernel Module? On second thought...
Oh my! Judging from the large number of *flames* I got for suggesting it, I guess a kernel module for X is not such a good idea after all. Oh well, I hope it was at least worth brainstorming. XFree86 *might* wish to consider a modulette to cover things that userland CAN'T do, like AGP, DMA, IRQ, and so on. Or maybe the modulette could grant I/O privileges on behalf of an X server that opens it (thus the X server doesn't require root privileges)? Perhaps some extensions to /dev/framebuffer? A smaller module may involve less overhead. Does the notion of a kernel module have ANY merit at all? Or was the idea complete garbage? PLEASE: Don't flame me, and if there are serious flaws with my ideas, please be specific so I know what to fix. _ Surf and talk on the phone at the same time with broadband Internet access. Get high-speed for as low as $29.95/month (depending on the local service providers in your area). https://broadband.msn.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
On Wed, 15 Oct 2003 20:38:44 +, Raymond Jennings wrote: Oh well, I hope it was at least worth brainstorming. Brainstorming is (almost) never a bad idea. XFree86 *might* wish to consider a modulette to cover things that userland CAN'T do, like AGP, DMA, IRQ, and so on. AGP stuff can be done in usermode. Most the DRI drivers DO include a kernel module for handling DMA and interrupts. The idea of a generic DMA/IRQ handler is somewhat attractive, but the various graphics chips are so very different that doing anything generically is quite difficult. Or maybe the modulette could grant I/O privileges on behalf of an X server that opens it (thus the X server doesn't require root privileges)? You get the same spoofing issue here. If an unprivileged XFree86 server can gain access to the kernel module, then any arbitrary unprivileged application can do so as well. You really need some way to identify the XFree86 server as trusted. In Linux today, the only mechanism for doing that is suid root. Does the notion of a kernel module have ANY merit at all? Or was the idea complete garbage? As we have said, many of the drivers DO have kernel modules for implementing OpenGL acceleration. However, there is a tradeoff. You're getting additional functionality, in exchange for an operating system dependency and the inherent stability risks in moving stuff to the kernel. There is clearly a threshhold beyond which the tradeoff makes good sense. My key point is that the threshhold needs to be set rather high. It's not that the kernel idea is unconditionally bad. It's just that, for the typical 2D driver, the gain isn't worth the pain. -- - Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VIA's Savage Drivers
On Wed, Oct 15, 2003 at 09:50:40AM -0700, Tim Roberts wrote: Some months ago, VIA released an XFree86 Savage driver in source form that included, among other things, a DRI driver and XvMC support. Has that code been integrated into the XFree86 source tree? Will it make XFree86 4.4? Or is it still waiting in limbo for someone to do the integration? I created the savage-1-0-0-branch in the DRI tree and merged the 2D these pieces together. Unfortunately the 3D driver is based on Mesa 3.4.x from the XFree86 4.2.0 days, and needs some work to bring it up-to-date. I suggest you check out that branch from the DRI. It certainly won't make 4.4. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Kernel Module? On second thought... plus OT: Flame fest
Does the notion of a kernel module have ANY merit at all? Or was the idea complete garbage? Obviously your idea isn't complete rubbish, but you are preaching to a very particular crowd, so you need to make sure you're ideas aren't contrary to their personal biases, sad isn't it? Ok, now that we have that over with, on with my response. I think the concept of having kernel modules handling some tasks has merit, but two things should smack you in the face whenever you conceder it. Note, DRI is basically what you are looking for, but I like to rant, so here goes: 1. Portability Since the module would have to be kernel dependent, porting an XServer to another platform becomes difficult. It is already difficult enough to support new platforms as it is in X. The stipulation to get into XFree is that any platform dependent changes to the server must be optional. If the functionality you are requesting applies to changing the baseline X Server, you better make sure that it works on all the platforms Xfree Supports, which is a lot. The way I read your comment, it seemed like a broad strokes change to the entire system. 2. Change Control If you know anything about Xfree86, you will see that the maintainers don't like to depend on code externally. Making a kernel module, you are taking the ability of the XFree developers to have total control over the timing and release procedures of the module. This is also a bad candidate for versioning incompatibilities inside the current iteration of the system. soap_box flame_rating=100% I really with that there were more well defined API's in Xfree which would mitigate any need for compiling module X for server Y. It is really stifling to work with an open source system that only introduces changes once a year. I am not talking about the X Protocol specs, but the basic building blocks of the server itself. It would be nice to add a newly developed extension, form of encryption, or whatever without having to get everything rebuilt for me. Following the comments from a previous commenter, X is too big for mear mortals to manage is a whole, and it'd be better IMHO to see some basic separation put in, and have some document like the architecture and framework of the Xfree86 server which ties all the discrete parts together. I can only imagine that the original goal of Xfree86 was to make a fully self-contained X server to compete with the big guys in the market. The problem is that today there are throngs of people making things in the user / toolkit space that are now redundant with those in Xfree and barely maintained. An example breakup for binary releases: Xfree86 Server Xfree86 Server feature insert feature here Xfree86 Server module insert module here XFree86 Client Xfree86 Common XFree86 Client Tools Xfree86 Server Devel Xfree86 Client Devel Xfree86 Common Devel XFree86 Fonts How you define features is sadly ambigious, maybe something a little broader than just X extensions. This may never be possible with Xfree's architecture, I am not versed enough to make a call. Core system changes are fine at 1 year, Feature updates can be released quarterly, Driver releases should be monthly Of course the implementation of such a scheme involves a lot discussion larger than my soap box. /soap_box ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: More details about a kernel module (by GPfault)
Hmm... An IOCTL shouldn't have any more overhead than reading or writing to a file... I'd think that the kernel is lightning fast at *dispatching* the IOCTL. Handling it is something else entirely and depends on how long the device driver decides to take. It's device specific. I don't understand how that was a rhetorical question. My sense of humor is very blunt, and I don't get the punchline. From: Juliusz Chroboczek [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: More details about a kernel module (by GPfault) Date: 14 Oct 2003 11:41:59 +0200 RJ Just add some IOCTL's for hardware acceleration). How much overhead does an ioctl involve ? (Rhethorical question.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel _ Add MSN 8 Internet Software to your current Internet access and enjoy patented spam control and more. Get two months FREE! http://join.msn.com/?page=dept/byoa ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Forgiviness! I repent!
On Wed, 15 Oct 2003, Raymond Jennings wrote: Oh great XFree86 spirits! Please forgive my transgressions! I have sinned in ignorance! I repent! (:D) It was I who suggested the kernel module. It has since been considered heresy. My apologies. There's nothing wrong with kernel modules, per se. It's just that XFree86 exists, and has existed, on quite a bit more platforms that just Linux. 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: More details about a kernel module (by GPfault)
On the scale of the speed of graphics operations, IOCTLs are very expensive. Compare how many IOCTLs a second you can do compared to things like triangle rates of modern graphics hardware (which are over a 100 Million a second). Mark. On Wed, 15 Oct 2003, Raymond Jennings wrote: Hmm... An IOCTL shouldn't have any more overhead than reading or writing to a file... I'd think that the kernel is lightning fast at *dispatching* the IOCTL. Handling it is something else entirely and depends on how long the device driver decides to take. It's device specific. I don't understand how that was a rhetorical question. My sense of humor is very blunt, and I don't get the punchline. From: Juliusz Chroboczek [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: More details about a kernel module (by GPfault) Date: 14 Oct 2003 11:41:59 +0200 RJ Just add some IOCTL's for hardware acceleration). How much overhead does an ioctl involve ? (Rhethorical question.) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: VIA's Savage Drivers
On Mer, 2003-10-15 at 21:07, Alex Deucher wrote: the 3D drvier needs to be updated to mesa 5.x. Not much work has been done on it and I think there are some issues with the 2D driver. There's no way it will make it into 4.4.0. the current code is on a branch in DRI cvs. If you are interested in helping, please do. 2D is stable. AlanH added some core infrastructure bits that will improve it but its current form has only two known bugs. The 3D is another matter - the last code I threw at people runs glxgears sometimes and thats it 8) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] Re: VIA's Savage Drivers
Alan, that's the CLE266/via driver, right? the savage driver is still barely touched as far as I know. there was some talk of shelving the old savage_1-0-0 branch and starting a new one on savage_1-0-1 since the old one needed so many changes to get synced up to the trunk. Alex --- Alan Cox [EMAIL PROTECTED] wrote: On Mer, 2003-10-15 at 21:07, Alex Deucher wrote: the 3D drvier needs to be updated to mesa 5.x. Not much work has been done on it and I think there are some issues with the 2D driver. There's no way it will make it into 4.4.0. the current code is on a branch in DRI cvs. If you are interested in helping, please do. 2D is stable. AlanH added some core infrastructure bits that will improve it but its current form has only two known bugs. The 3D is another matter - the last code I threw at people runs glxgears sometimes and thats it 8) __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
