Re: Logitech Elite Keyboard Layout
On Sun, 19 Oct 2003, J E Dog wrote: I have writen an xkb layout for the Logitech Elite Keyboard. Maybe someone can use it or it will be included into XFree. All code submissions and patches, should be filed in bugzilla at: http://bugs.xfree86.org as individual uncompressed file attachments (not cut and pasted into the comment field). All patches should be in the unified diff format and created against the current CVS head preferably. A unified diff can be created by doing: diff -Naur xc.orig xc yourpatch.patch Excuse me, but I have never seen that rule on the website anywhere. I didn't say that it was a rule on the website anywhere. Please point out where I said that. Where did it come from? It came from the will of hundreds and thousands of open source developers who dislike context diffs and other forms of diff patches, and prefer the unified diff format, as unified diff format seriously saves a lot of time when you're a developer working on a software project, in particular a project as large as XFree86. Is this your particular preference? Why yes it is. And it's the most popular preference of most developers working on most software projects who even know how about how to generate patches with diff and apply them with patch also. The majority of developers working on any OSS software that I know, be it XFree86 or something else usually go as far to straight out refuse all patches that are not in unified diff format. Unified diff is the easiest to read, easiest to understand, and the easiest to hand edit should the need arise. It also applies much more cleanly than the other formats. I'm only preaching to the choir while educating you however, so I wont bore the rest of the people who already know and agree with me, by going into further detail. If so you should state so plainly and not make it a rule of the Project's. Is this your personal opinion? Or the opinion of the XFree86 project? If so please state than plainly when making useless comments in response to useful suggestions by others. In my opinion, you don't exactly contribute much to the XFree86 project other than a rude attitude and obnoxious comments shouted from your high horse from time to time for your opinion to matter much to me about pretty much anything anyway. I'm surprised that I haven't procmailed you to /dev/null yet. And to be quite honest, I'd be more than happy if you'd do the same to me, if for no other reason than I'd see both less of your postings *and* your generally useless responses. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Accellerated trident_drv.o for XFree 4.2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 / Alan Hourihane [EMAIL PROTECTED] was heard to say: | You need to download the libpcidata and libscanpci.a modules too for | XFree86 4.2.x. Bingo! Thank you, Alan. Be seeing you, norm - -- Norman Walsh [EMAIL PROTECTED] | He who will not reason is a bigot; he http://nwalsh.com/| who cannot is a fool; and he who dares | not is a slave.--Sir William Drummond -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 http://mailcrypt.sourceforge.net/ iD8DBQE/lAgIOyltUcwYWjsRAs39AKCqcGyeF00O4oISvP7SVUkKCpnK2gCdFvBX Hct9i4Ho8Ry9LmKHVPOi43Q= =6oz4 -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DRI proprietary modules
John Dennis wrote: For DRI to work correctly there are several independent pieces that all have to be in sync. * XFree86 server which loads drm modules (via xfree86 driver module) * The drm kernel module * The agpgart kernel module Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The Nvidia drivers do not use DRI. The 3dlabs, ATI, PowerVR, and Matrox (for their Parhelia hardware) drivers do. They will *all* replase the DRM kernel module, the XFree86 2D driver, and the client-side 3D driver (the *_dri.so file). Most include a custom libGL.so that provides some added functionality. The client-side 3D driver and the DRM kernel module are very tightly related, and should be considered a single entity (for the most part). The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Don't bring Mesa into this. Mesa fundamentally has nothing to do with DRI. It just so happens that all of the open-source DRI drivers use Mesa, but there is no such requirement. AFAIK, *none* of the closed-source drivers use any code from Mesa. Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? I think both the ATI and Nvidia drivers have the option to either use agpgart or an internal implementation. I'm fairly certain that the PowerVR, 3dlabs, and Matrox drivers all use agpgart exclusively. All of the drivers, closed-source or open-source, depend on the agpgart interface. Changing that interface in a non-backwards compatible will break them all. I guess my question is, what changes are under consideration? ___ 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)
Jakub Jelinek wrote: 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)? 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. Sorry for taking so long to reply. I was taking a few days off. :) libGL.so needs to export XF86DRI*, __glXFindDRIScreen, and a few _glapi functions on all platforms that support DRI (i.e., Linux and *BSD currently). Do a nm /usr/X11R6/lib/modules/dri/*_dri.so | grep ' U _glapi' | sort -u to see which ones. On all platforms all symbols matching gl[A-Z]* need to be exported. Other than that I don't think anything needs to be exported by libGL.so. I *believe* that the *_dri.so files only need to export __driCreateScreen. There are some other symbols that need to be exported in DRI CVS, but that code isn't in XFree86 CVS AFAIK (and won't be until after 4.4.0). Thanks for tackling this! ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Configuring Function keys with mouse pointer
On Tue, Oct 07, 2003 at 12:09:34PM +0200, [EMAIL PROTECTED] wrote: Can I in a multi monitor situation configure the Function Keys so that for example the F1 key will put the mouse pointer on Screen 1 ? Best regards, Marcel Stegehuis (Pardon my vague understanding of multi-monitor mode's workings under the hood, as I joined this list to get a better hang of mouse behavior and absorb a bit of modern X programming savvy by osmosis. If I'm wrong about anything corrections from saner souls are welcomed.) If multiple monitors is handled as a giant screen of broader pixel range, then simple repositioning of the mosue cursor to a given pixel location should be sufficient. If, as a user, you can use -geometry to place new windows on any of your monitors, then I would expect the answer to be yes. That lends the answer to being a window manager function - if it (1) lets you jump the mouse cursor that way (rather than merely new windows), and (2) allows assignment of function key to invoke that ability, then sure, I don't see why not. If you're writing a WM that wants to do this I hope one of the others can do it already; that would make it easy to see how they coded this up. . | . Heather Stern | [EMAIL PROTECTED] ---*--- Starshine Technical Services - * - [EMAIL PROTECTED] ' | ` Sysadmin Support and Training |(800) 938-4078 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
Mike A. Harris wrote: On Fri, 17 Oct 2003, David Fox wrote: I think that the wisest approach is, instead of suggesting a kernel module to the XFree86 folks, you do two things. First, suggest a kernel module to the Linux folks that implements a protocol for accessing the resource you are trying to use. Then you go to the XFree86 folks and suggest a module to utilize that protocol in the X server. [snip] What _specific_ area of XFree86 performance are you (or anyone else) thinking needs improvement, what solutions have you investigated or even thought about which could improve this performance by modifying XFree86 itself, a driver, Mesa, or other userland code? If you do think the kernel might help for this problem, what steps have you taken to determine if that is truely reasonable, and have you tested your theory? Have you discussed that one small idea with other developers to see what they think about the alleged problem, wether it even really is a problem at all, how important it is, what other solutions there might be, etc. etc. etc. All of this lets stuff things in the kernel, because kernel code is automatically 2 times faster right? stuff gets boring fast. Show me the code. I have no code to show ;-) but I have a case where a kernel module is unavoidable to get out of the statu quo : M. Voijkovich asked about the use of sched_yield() in order to wait for the FIFO to process a big enough part of the DMA buffer before we try to refill it; his idea was to smartly release the CPU because we know that the driver will have to wait quite a while before the GPU has processed the datas. But we also need to get the CPU back fast enough in order to have a unbroken stream of data fed to the GPU.Now the driver is busy looping (correct me if I wrong) which is a waste of CPU. Using sched_yield() for 2.6.x linux kernels will lead to bad latency (basically we will reacquire the CPU very lately). The last alternative (at least following R. Russel and R.M. Love) is to have a kernel module which can poll the DMA to see how much has already been sent to the GPU, and when enough has been processed, this kernel module wakes up the driver in userland (using futexes). This approach could work with all these types of rather long waits where it is not really smart to busy loop (one assumption is that the wait can be long enough that we will consume our whole timeslice busy looping, which will also lead to a bad score on interactiveness on newer linux kernels, and also we will have to wait until we reacquire the CPU). R. Russel seems to be OK to help if the XFree guys wanted to go this way. I must add that M. Vojkovich did not like the idea of a kernel module. My 2 cents... Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Kernel Module? On second thought...
Emmanuel ALLAUD wrote: Mike A. Harris wrote: On Fri, 17 Oct 2003, David Fox wrote: I think that the wisest approach is, instead of suggesting a kernel module to the XFree86 folks, you do two things. First, suggest a kernel module to the Linux folks that implements a protocol for accessing the resource you are trying to use. Then you go to the XFree86 folks and suggest a module to utilize that protocol in the X server. [snip] What _specific_ area of XFree86 performance are you (or anyone else) thinking needs improvement, what solutions have you investigated or even thought about which could improve this performance by modifying XFree86 itself, a driver, Mesa, or other userland code? If you do think the kernel might help for this problem, what steps have you taken to determine if that is truely reasonable, and have you tested your theory? Have you discussed that one small idea with other developers to see what they think about the alleged problem, wether it even really is a problem at all, how important it is, what other solutions there might be, etc. etc. etc. All of this lets stuff things in the kernel, because kernel code is automatically 2 times faster right? stuff gets boring fast. Show me the code. I have no code to show ;-) but I have a case where a kernel module is unavoidable to get out of the statu quo : M. Voijkovich asked about the use of sched_yield() in order to wait for the FIFO to process a big enough part of the DMA buffer before we try to refill it; his idea was to smartly release the CPU because we know that the driver will have to wait quite a while before the GPU has processed the datas. But we also need to get the CPU back fast enough in order to have a unbroken stream of data fed to the GPU.Now the driver is busy looping (correct me if I wrong) which is a waste of CPU. Using sched_yield() for 2.6.x linux kernels will lead to bad latency (basically we will reacquire the CPU very lately). The last alternative (at least following R. Russel and R.M. Love) is to have a kernel module which can poll the DMA to see how much has already been sent to the GPU, and when enough has been processed, this kernel module wakes up the driver in userland (using futexes). This approach could work with all these types of rather long waits where it is not really smart to busy loop (one assumption is that the wait can be long enough that we will consume our whole timeslice busy looping, which will also lead to a bad score on interactiveness on newer linux kernels, and also we will have to wait until we reacquire the CPU). R. Russel seems to be OK to help if the XFree guys wanted to go this way. I must add that M. Vojkovich did not like the idea of a kernel module. My 2 cents... Bye Manu Hmm, replying to myself : I read that the DRI kernel module addresses certain issues with DMA/IRQ and others. Is there any good reason that would prevent 2D drivers to use the API provided by this module? Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
