Re: XFree86 module compatibility?
On Tue, 4 Mar 2003, Kendall Bennett wrote: I know I have asked this before, but I can't seem to find my emails and the mailing list archive does not seem to be responding. What sort of back/forward compatibility is there with the XFree86 driver modules? From memory last time I tested this, if I compile a 4.2.0 module it will work with any version of 4.2.x, but it will fail to load on 4.3.x or 4.1.x. So right now we are thinking of building modules for 4.0.x, 4.1.x, 4.2.x and 4.3.x and shipping all four modules with our installer (which will auto choose which one to install). Is that the correct approach? Or should we be building modules for each released version of XFree86 (ie: 4.1.0, 4.1.2, 4.1.3, 4.2.0, 4.2.1 etc)? The compatibility we strive for (but admittedly don't always accomplish) is best expressed as Version(module) = Version(core binary) There are also inter-module dependencies to consider. 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: Multiple Video Consoles
Jonathan,
could you also post your XF86Config file? I have some ideas on how
to extend this. It's still kind of a hack, but here goes:
add an option to the radeon driver, say MergedFB or something like
that. when that option is set to TRUE, it would skip the sections of
code that you have commented out.
next add sub options for MergedFB like:
Option MFB-Xres 2048
Option MFB-Yres 768
these would set the virtualX and Y instead of having to hardcode them.
it's still hackey, but would clean it up a bit and allow run time
configuration.
Alex
--- Jonathan Thambidurai [EMAIL PROTECTED] wrote:
I posted the following message to the DRI-devel lists the day before
yesterday and was told it might be of interest to this discussion.
Additionally, I have attached some diffs, contrary to what is said as
follows.
I am pleased to report that thanks to the guidance Jens Owens gave in
a
previous message, I have made 3D work on two heads simultaneously
(IIRC,
the ATI Windows XP drivers didn't do this). I have not provided a
diff
because it is quite a hack and very system specific, at the moment.
Effectively, I forced the virtual size to be 2048x768, hacked the
RADEONDoAdjustFrame() function to fix views as I wanted them, used
the
default cloning stuff to setup the second monitor, and removed all
the
conditionals that were preventing dual-head+DRI from working. I had
to
enable Xinerama (even though I have only one screen in the server
setup)
in the config file; otherwise, the desktop would end at 1024 instead
of
2048. The problem I mentioned in a previous post -- not enough
memory
for direct rendering w/ two screens -- was solved when I set it to 16
bpp. Does anyone have any ideas for a more elegant implementation of
this functionality, especially where the config file is concerned?
This
is the first real code I have done in the Xserver and any input would
be
appreciated.
--Jonathan Thambidurai
p.s. If there is something strange about the diffs, please tell me;
it
is the first time I generated any
--- /usr/local/src/XFree86.current/xc/programs/Xserver/GL/dri/dri.c
2002-12-05 10:26:57.0 -0500
+++ dri.c 2003-03-03 18:29:30.0 -0500
@@ -137,13 +137,13 @@
#endif
#if defined(PANORAMIX) || defined(XFree86LOADER)
-if (xineramaInCore) {
- if (!noPanoramiXExtension) {
- DRIDrvMsg(pScreen-myNum, X_WARNING,
- Direct rendering is not supported when Xinerama is enabled\n);
- return FALSE;
- }
-}
+/* if (xineramaInCore) { */
+/* if (!noPanoramiXExtension) { */
+/* DRIDrvMsg(pScreen-myNum, X_WARNING, */
+/* Direct rendering is not supported when Xinerama is
enabled\n); */
+/* return FALSE; */
+/* } */
+/* } */
#endif
drmWasAvailable = drmAvailable();
---
/usr/local/src/XFree86.current/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
2003-02-04 20:48:27.0 -0500
+++ radeon_driver.c 2003-03-03 19:16:23.0 -0500
@@ -2754,24 +2754,29 @@
xf86SetCrtcForModes(pScrn, 0);
/* We need to adjust virtual size if the clone modes have larger
- * display size.
+ * display size. JDTHAX04: hardcoding large virtual area
*/
if (info-Clone info-CloneModes) {
DisplayModePtr clone_mode = info-CloneModes;
while (1) {
- if ((clone_mode-HDisplay pScrn-virtualX) ||
- (clone_mode-VDisplay pScrn-virtualY)) {
- pScrn-virtualX =
- pScrn-display-virtualX = clone_mode-HDisplay;
- pScrn-virtualY =
- pScrn-display-virtualY = clone_mode-VDisplay;
- RADEONSetPitch(pScrn);
- }
+/* if ((clone_mode-HDisplay pScrn-virtualX) || */
+/* (clone_mode-VDisplay pScrn-virtualY)) { */
+/* pScrn-virtualX = */
+/* pScrn-display-virtualX = clone_mode-HDisplay; */
+/* pScrn-virtualY = */
+/* pScrn-display-virtualY = clone_mode-VDisplay; */
+/* RADEONSetPitch(pScrn); */
+/* } */
if (!clone_mode-next) break;
clone_mode = clone_mode-next;
}
}
+pScrn-virtualX = pScrn-display-virtualX = 2048;
+pScrn-virtualY = pScrn-display-virtualY = 768;
+RADEONSetPitch(pScrn);
+xf86DrvMsg(pScrn-scrnIndex, X_NOTICE,
+JDT HACK WORKING\n);
pScrn-currentMode = pScrn-modes;
xf86PrintModes(pScrn);
@@ -3463,18 +3468,18 @@
info-directRenderingEnabled = FALSE;
else {
/* Xinerama has sync problem with DRI, disable it for now */
- if (xf86IsEntityShared(pScrn-entityList[0])) {
- info-directRenderingEnabled = FALSE;
- xf86DrvMsg(scrnIndex, X_WARNING,
-Direct Rendering Disabled --
-Dual-head configuration is not
Re: Debugging in RH8?
Mike A. Harris [EMAIL PROTECTED] wrote: I am trying to debug XFree86 at the source code level on Red Hat 8.0 but not having much like. I force installed gdb-5.1.1-2.0xfree from the RPM file from Red Hat's site, but when I do 'gdb X' gdb crashes with a segmentation fault. gdb-xfree is currently not completely working solidly in 8.0 and later. It works for me to some extent but isn't perfect. I don't really grok gdb internals too well though, so I've gotten our gdb engineers to look into fixing gdb for once and for all in stock FSF gdb. No ETA unfortunately, but I'll likely announce it on devel@ though when there's something to play with that is useful. Ok, it sounds like I should perhaps back level my debugging machine to Red Hat 7.2 or 7.3? A guy working for me remote in Australia tells me that he is using the patched 5.1.1 just fine on RH 7.2... But when you do get this into the stock gdb, please let us all know ;-) Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debugging in RH8?
On Wed, 5 Mar 2003, Kendall Bennett wrote: I am trying to debug XFree86 at the source code level on Red Hat 8.0 but not having much like. I force installed gdb-5.1.1-2.0xfree from the RPM file from Red Hat's site, but when I do 'gdb X' gdb crashes with a segmentation fault. gdb-xfree is currently not completely working solidly in 8.0 and later. It works for me to some extent but isn't perfect. I don't really grok gdb internals too well though, so I've gotten our gdb engineers to look into fixing gdb for once and for all in stock FSF gdb. No ETA unfortunately, but I'll likely announce it on devel@ though when there's something to play with that is useful. Ok, it sounds like I should perhaps back level my debugging machine to Red Hat 7.2 or 7.3? A guy working for me remote in Australia tells me that he is using the patched 5.1.1 just fine on RH 7.2... I would recommend an rpm rebuild of gdb-xfree86 on 8.0 first to see if it is reliable enough for you or not, failing that in 7.3 it works pretty flawless for me. But when you do get this into the stock gdb, please let us all know ;-) Absolutely. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
On Wed, 5 Mar 2003, Marc Aurele La France wrote: On Wed, 5 Mar 2003, Kendall Bennett wrote: Is that the correct approach? Or should we be building modules for each released version of XFree86 (ie: 4.1.0, 4.1.2, 4.1.3, 4.2.0, 4.2.1 etc)? The compatibility we strive for (but admittedly don't always accomplish) is best expressed as Version(module) = Version(core binary) There are also inter-module dependencies to consider. So basically we should be able to compile with say 4.1.0 and have our module run on all greater versions of 4.x.0 right? Obviously YMMV, so we should probably test this. The downside of course is that we would much prefer to be compiling with the latest version of XFree86 rather than a backlevel version for our modules, but if we do that we will not be able to support older versions. Hence I am thinking that I should compile against the tip level in each sub version. Ie: 4.0.0, 4.1.0, 4.2.0, 4.3.0 etc so it will work with each minor revision of that branch (ie: 4.2.0 works with 4.2.1 through 4.2.99 which I already know). However if say I upgrade our development tree to 4.3.1, does that mean that the 4.3.1 driver will fail to load on a 4.3.0 install? The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Allow me to qualify that... The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on and provides the suport base you are willing to live with. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. 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
logitech ps/2++ updates
I have a patch that updates the Logitech PS/2++ protocol to support their mice with up to 10 buttons (currently they're only using 8 on the MX500 and MX700). The PS/2++ protocol now uses 6 bits to identify a packet instead of 4 as before. Apparently, there's a touchpad protocol that also used it (more on that later). Updated PS/2++ protocol: The identifier type bits are now 6 bits instead of 4: bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0 byte1 11 t5 t41MRL Button data byte2 t3 t2 t1 t0 d2 d110 X data byte3 d8 d7 d6 d5 d4 d3 d2 d1 Y data note: bit7, byte1 is 1 for external devices, 0 for internal ones name tdescription P0 - 0x0C - attached device type (corded mouse or receiver) P1 - 0x0D - roller and buttons 4 5 info P2 - 0x0E - buttons 4,5,6,7,8,9,10 info ... (other packet types aren't used/useful to X) This is the new P2 packet: bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0 byte1 11001MRL byte2 1110 B5 B410 byte3 0 B10 B9 B8 B7 B6 B5 B4 B6 = task switch button B7 = SMS up button B8 = SMS down button B9/10 are not yet used in current mice There are also 2 feature additions (not PS/2++): Option SmartScroll (boolean) in the config enables/disables auto-scrolling on the SMSup/down buttons on the MX500/700. Also, 800 cpi resolution is now supported on mice that support it in hardware (Dual Optical, MX300/500/700, ...). Hopefully this will make high sensitivity users happy :) Here's my patch: http://yhbt.net/normalperson/files/xfree86/4.3.0_logitech_ps2.patch The downside of this patch is that some touchpad users that specify MouseManPlusPS/2 will probably need a new protocol defined for them. -- Eric Wong ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Marc Aurele La France [EMAIL PROTECTED] wrote: The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Allow me to qualify that... The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on and provides the suport base you are willing to live with. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Right, we plan to test with every version of XFree86 to ensure compatibility (along with tons of Linux distros; ugh). We would like to support all versions of XFree86 with our module, and we have no problem building different modules as necessary to support those versions. What I am trying to figure out is what the smallest set of module versions I can build to ensure compatibility. It would be nice if I could build a 4.0.3 module and have it work with 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all 4.0.x versions, right? Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
On Wed, 5 Mar 2003, Kendall Bennett wrote: Marc Aurele La France [EMAIL PROTECTED] wrote: The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Allow me to qualify that... The binaries you provide for your driver should be generated against the earliest (public) XFree86 version that provides the functionality your driver depends on and provides the suport base you are willing to live with. If that means 4.1.0, then that means 4.1.0. This does not absolve you of the responsibility to ensure the thus-generated binary works with later core binary versions. Right, we plan to test with every version of XFree86 to ensure compatibility (along with tons of Linux distros; ugh). We would like to support all versions of XFree86 with our module, and we have no problem building different modules as necessary to support those versions. What I am trying to figure out is what the smallest set of module versions I can build to ensure compatibility. It would be nice if I could build a 4.0.3 module and have it work with 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all 4.0.x versions, right? Nothing will work with all 4.0.x versions. 4.0.0 XAA isn't binary compatible with 4.0.1 and newer XAAs. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Internal documentation
On Mon, 3 Mar 2003 10:54:16 -0600 jkjellman [EMAIL PROTECTED] wrote: I am working on modifying an input driver (or two :-) and am having a little trouble. I cannot find man pages or other documentation on internal X calls. For example, xf86Msg, xf86OpenSerial, etc. I have figured out some of these based on usage in the source files, but the less obvious ones are becoming a problem. For example, xf86PostMotionEvent has a series of parameters, most of which are hard coded in the drivers I am looking at. While I can search and read source code, this is not prefered as it is very time consuming when you know little if anything ;-) I'm doing very similar and, too, am having much trouble finding any information on how things work, etc... If I find anything I'll let you know, but for now the best I can suggest is http://www.atomised.org/docs/XFree86-4.2.1/ -- Paul Evans (3rd Year CompSci at Pembroke College, Cambridge, England) [EMAIL PROTECTED] (university) [EMAIL PROTECTED] (alternate) ICQ# 4135350 Registered Linux User: 179460 http://www.srcf.ucam.org/~pe208/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Feigning erudition, Kendall Bennett wrote: % Marc Aurele La France [EMAIL PROTECTED] wrote: % % The binaries you provide for your driver should be generated against the % earliest (public) XFree86 version that provides the functionality your % driver depends on. If that means 4.1.0, then that means 4.1.0. This does % not absolve you of the responsibility to ensure the thus-generated binary % works with later core binary versions. % % Allow me to qualify that... % % The binaries you provide for your driver should be generated against the % earliest (public) XFree86 version that provides the functionality your % driver depends on and provides the suport base you are willing to live % % with. If that means 4.1.0, then that means 4.1.0. This does not absolve % % you of the responsibility to ensure the thus-generated binary works with % later core binary versions. % % Right, we plan to test with every version of XFree86 to ensure % compatibility (along with tons of Linux distros; ugh). We would like to % support all versions of XFree86 with our module, and we have no problem % building different modules as necessary to support those versions. What I % am trying to figure out is what the smallest set of module versions I can % build to ensure compatibility. We fight the tons of Linux distros; ugh battle at work. Rather, we quickly decided that we *couldn't* fight that battle and win, so we chose a double handful of distributions that: ° We believe represents significant shares of the installed Linux base ° Complements the strengths of our developers, QA personnel, writers, and in-house Linux users (we're a mixed Linux/Windows shop) Off the top of my head, we chose 2 recent Linux-Mandrake releases, the last 3 Red Hat Linux releases, the most recent SuSE release, and Debian Potato and Woody. I suppose we'd add your favorite distro here if a customer waved enough shekels at us to make the QA effort worthwhile. % It would be nice if I could build a 4.0.3 module and have it work with % 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all % 4.0.x versions, right? I'd venture to say you just have to test against the N releases you think you can afford or have the resources to support. Kurt -- God may be subtle, but He isn't plain mean. -- Albert Einstein ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: miTranslate related problems.
Around 21 o'clock on Mar 5, Mark Vojkovich wrote: So am I right that when pGC-miTranslate is true, the caller needs to add the drawable origin to FillSpans, SetSpans and PushPixels? Yes, the drawable origin must be added into all of the parameters to these functions when the top-most such function is called. If so, doesn't that mean that miDCPutBits is broken, and also FillSpans, SetSpans and PushPixels in both shadow framebuffer layers? Yes, miDCPutBits looks broken, but the only drawables ever used are the root window and pixmaps both of which used to have zero origins. On the other hand, the shadow frame buffer layers are just passing arguments through from above and the offsets should already have been added in by functions above the shadow code. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: miTranslate related problems.
On Wed, 5 Mar 2003, Keith Packard wrote: Around 21 o'clock on Mar 5, Mark Vojkovich wrote: So am I right that when pGC-miTranslate is true, the caller needs to add the drawable origin to FillSpans, SetSpans and PushPixels? Yes, the drawable origin must be added into all of the parameters to these functions when the top-most such function is called. If so, doesn't that mean that miDCPutBits is broken, and also FillSpans, SetSpans and PushPixels in both shadow framebuffer layers? Yes, miDCPutBits looks broken, but the only drawables ever used are the root window and pixmaps both of which used to have zero origins. Offscreen pixmaps don't so this has been broken since 3.9.x. It's obviously not a common case if I'm just seeing this now for the first time. On the other hand, the shadow frame buffer layers are just passing arguments through from above and the offsets should already have been added in by functions above the shadow code. OK, I'll change them then. I suppose the miTranslate check should go in miDCPutBits. Do you think I should bother with miTranslate checks in the shadow framebuffer layers? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Kendall, You should also test against different distributions, different compilers (gcc 3.2.x versus 2.95) and different C libraries. In particular, modules compiled with gcc 2.95 might not work with XFree86 compiled with gcc 3.2.x and vice versa.. best Vladimir Dergachev ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: miTranslate related problems.
Around 23 o'clock on Mar 5, Mark Vojkovich wrote: Offscreen pixmaps don't so this has been broken since 3.9.x. It's obviously not a common case if I'm just seeing this now for the first time. The core cursors are all 16x16, which is presumably smaller than the pixmap code would put in off-screen memory for cards that didn't have hardware cursor support. Still, it's a bit surprising that no-one has ever seen a problem with this (or at least no-one has complained here). OK, I'll change them then. I suppose the miTranslate check should go in miDCPutBits. Do you think I should bother with miTranslate checks in the shadow framebuffer layers? Yes, miDCPutBits should check miTranslate. The shadow layers *mustn't* be changed -- the miTranslate checks would have occured in whatever function was calling through the shadow layer: miPolyArc shadowPushPixels fbPushPixels The miTranslate check is done in miPolyArc before shadowPushPixels is called. If this were broken, lots of stuff wouldn't work on shadow frame buffers. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: miTranslate related problems.
Around 0 o'clock on Mar 6, Mark Vojkovich wrote: You don't understand. The shadow framebuffer SetSpans, FillSpans and PushPixels ARE CURRENTLY TRANSLATING. Ah. Yes, I was confused. the miext/shadow code doesn't translate the data on the way to the underlying code (I thought you were saying it should), but it does translate coordinates when computing the damage region. Oops. I think they never actually get used which is why you don't see more stuff broken. Yes, they can't get called unless someone invokes them from outside the rendering code -- normally, they're called from general mi rendering routines below the shadow layer. Except for PushPixels in the software cursor code. Sorry for the mass confusion here. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
