Re: Multiple video consoles
On Mon, Mar 03, 2003 at 09:46:40PM -0500, David Dawes wrote: 2) a way to tell the framebuffer/viewport sizes for each supported resolution, something like : SubSection Display Mode 1024x768 Viewport 0 0 1024 768 Viewport 0 0 800 600 Viewport 0 0 640 480 EndSubSection or maybe SubSection Display Framebuffer 1024 768 Modes 1024x768 800x600 640x480 EndSubSection Erm, this is the other way around, the Modes give the Framebuffer size, and not the other way around, so, this one woudln't work. Which would tell the driver that we only support outgoing resolution of 1024x768, but that framebuffer resolution of 1024x768, 800x600, and 640x480 are ok, and that we should scale from them to the 1024x768 one. Maybe the syntax is not the best, but you get the idea. Actually, I don't understand what you're trying to do that can't be done already. The user shouldn't care that the panel is 1024x768 (other than that it's the max available mode resolution). The driver should figure that out and take care of scaling the user's 800x600 mode request to the physical output size of 1024x768. As a user, when I specify 800x600, I just want the physical screen to display an 800x600 pixel area on the full screen. I don't care of it's an 800x600 physical output mode or if the 800x600 is scaled to some other physical output resolution. Yes, but we need to change the way we calculate output mode, and use the fixed resolution, autodetected or with a monitor option like you propose below. The only new feature I see is that arbitrary scaling allows a potentially much finer set of mode sizes than we're currently used to, and this would be very useful for allowing real-time zooming and tracking windows (including resizes). That can be done with most modern CRTs too (with some horizontal granularity limits), but I imagine that zooming would be more seemless with the scaler method though than implementing it with CRT resolution changes. Yes. I could do this by using an outgoing resolution size in the device specific section, but this would not work best, since all the logic doing the mode setting now is done for the resolution in the display setting. Can the driver query the panel's size? If it can't, then it needs to be supplied somewhere. It could be a new Option in the Monitor section that the driver checks for. It would be best if the driver can auto-detect it though. I guess it can, DDC should be able to provide that, but i haven't got to there, and anyway, some monitor may have broken DDC, so better think of a Option for it, in the monitor section would be the best place for it. I strongly advocate that you take in account such separation of the outgoing resolution and the framebuffer size in any future configuration scheme. We already have the Virtual size, which is the framebuffer size, and allows it to be separated from the viewport (mode) sizes. I don't think the outgoing resolution belongs in the Screen/Display sections. It should be between the Monitor data and the driver, with the driver using this information to determine the maximum viewport (mode) size allowable. Yes, but consider how the current display section works. You use the mode to specify outgoing resolution, but apart from the builtin mode, there is no guarantee that the string used for the modes even correspond to said resolution, the user are used to this, but if we are going to do scaling, it really don't make sense to use 800x600 as mode, when what you really want to say is that you want a resolution of 800x600. Also, if you still want to use a virtual screen bigger than the actual one, you still would need to specify the viewport. SubSection Display Virtual 1600 1200 Mode 1024x768 (outgoing mode). Resolution 1280 1024 Resolution 1024 768 Resolution 800 600 Resolution 640 480 EndSubSection This way, we would have a 1600x1200 virtual screen, an outgoing resolution of 1024x768, which could be specified in the monitor section, and resolutions of 640x480 upto 1280x1024. Sure, you could also use the modes, but you would give to much info, after all you would only need the size of the mode, and not the rest of it. Some of the users of your driver probably will, so it's worth testing with it. Sure, but, err, its proprietary software i have no access too, right ? It never hurts to ask for a copy as a driver developer. The worst they can say is no. I find vmware very useful personally as well as for XFree86-related stuff (especially multi-platform build testing). Ok, Will be asking them. Friendly, Sven Luther ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: HW/SW cursor switching broken?
Keith Packard writes: Around 0 o'clock on Mar 4, Mark Vojkovich wrote: This is the core SW cursor not the ARGB SW cursor, though I haven't tried ARGB SW cursors (I forgot how to set one as the root cursor). $ XCURSOR_THEME=redglass XCURSOR_SIZE=256 xsetroot -cursor_name shuttle I guess I'll have to set a flag in the driver and ignore the SetCursorColors request when it's called while an ARGB cursor is displayed. The radeon driver already has such a flag. Perhaps we should put code into the hw cursor layer as well (in case a future driver forgets). Yes, it makes sense to have this code in the common layer. One issue here is that cursors sent in ARGB format which are actually two color cursors get mapped by the extension to core cursors, and so RecolorCursor actually has an effect on them. I think this is a bug which should get fixed up in DIX land though. This effect is different from what a function that has originally been implemented for a 1 bit source/mask cursor does. Our APIs are way loosely defined. We need to define much stricter what the driver can expect at certain stages and what is expected from the driver and not change the behavior without notice. This is not the only place where ambiguities and later introduced changes cause unintended side effects. VT switching is another example of a constant source of trouble. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: KeyBoard BUG on sparc/sparc64 in 4.3.0 too.
Balint Cristian wrote: Regard to that one BUG with the mention that it persist in 4.3.0 too and any CVS too: By Rene: http://marc.theaimsgroup.com/?l=xfree86m=104526841725691w=2 By mysef: http://marc.theaimsgroup.com/?l=xfree86m=104385693307371w=2 I send more deBug: http://marc.theaimsgroup.com/?l=xfree86m=104385720707941w=2 The reason of this bug is a change : 656. Make SysRq generate the same keycode as PrtScrn, and Break the same : keycode as Pause (#A.1160, Owen Taylor). which added into an xf86PostKbdEvent procedure a code : /* : * PC keyboards generate separate key codes for : * Alt+Print and Control+Pause but in the X keyboard model : * they need to get the same key code as the base key on the same : * physical keyboard key. : */ : if (scanCode == KEY_SysReqest) : scanCode = KEY_Print; : else if (scanCode == KEY_Break) : scanCode = KEY_Pause; But for a Sun's type5 keyboard it means something like if (code == 'letter L') code = 'letter B' if (code == 'comma')code = 'letter V' A simple fix for this issue could be a moving this code to the part of xf86PostKbdEvent which is being executed for PC keyboards only. --- xc/programs/Xserver/hw/xfree86/common/xf86Events.c.orig Tue Mar 4 18:34:31 2003 +++ xc/programs/Xserver/hw/xfree86/common/xf86Events.cTue Mar 4 18:41:45 2003 @@ -531,6 +531,17 @@ } /* + * PC keyboards generate separate key codes for + * Alt+Print and Control+Pause but in the X keyboard model + * they need to get the same key code as the base key on the same + * physical keyboard key. + */ + if (scanCode == KEY_SysReqest) +scanCode = KEY_Print; + else if (scanCode == KEY_Break) +scanCode = KEY_Pause; + + /* * and now get some special keysequences */ @@ -819,17 +830,6 @@ #ifdef XKB } #endif - - /* - * PC keyboards generate separate key codes for - * Alt+Print and Control+Pause but in the X keyboard model - * they need to get the same key code as the base key on the same - * physical keyboard key. - */ - if (scanCode == KEY_SysReqest) -scanCode = KEY_Print; - else if (scanCode == KEY_Break) -scanCode = KEY_Pause; /* * Now map the scancodes to real X-keycodes ... -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Misleading Makefile samples for Linux ?
On Mon, 2003-03-03 at 16:09, David Dawes wrote: Is it safe these days to unconditionally use /lib/modules/`uname -r`/build for $LINUX_SRC_DIR? It's probably as good a _default_ as any. We shouldn't make it too hard to change though. Will a single Makefile.kernel work for all versions of the kernel, and handle various incompatibilities that arise from time to time that the current Makefile.linux is forced to work around? It can be made to work without much difficulty, yes. For hints see http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/drivers/mtd/GNUmakefile?rev=1 http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/drivers/mtd/Makefile?rev=1 http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/drivers/mtd/Rules.make?rev=1 You don't actually need to muck with Rules.make if you don't want to support 2.2 kernels, IIRC. If so, then that's definitely the way to go. I'd love to see something cleaner than what we currently have (the Makefile for the FreeBSD drm modules is very clean). Well if you only really care about i386 PeeCee builds and 2.4 or 2.2 kernels you can happily hard-code your CFLAGS and root around to find suitable headers, but if you want it to be portable and future-proof you really ought to be using 'make SUBDIRS=...'. There are problems with that approach too -- some distributions' kernel-source packages are broken as shipped, and you need to make mrproper, copy the relevant config from the 'configs' directory and 'make oldconfig dep' before you can build external modules. But that breakage needs to be fixed anyway, so I wonder whether we need to bother to work around such brokenness? -- dwmw2 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: how to swap bit-order on a Xfbdev X-Server
Around 7 o'clock on Mar 4, Martin Gruber wrote: Can anybody give me a hint, if there is already a switch/define to change the bit-order in a byte for the kdrive Xfbdev XServer or tell me, where to The easiest way is to implement this with a shadow frame buffer; the fb code doesn't currently support byte-order != bit-order. Or, you can go and whack the code to swap accesses, fb isn't that much code (Xserver/fb). -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
patch to make 4.3.0 build on FreeBSD 5.0-Current alpha
So 4.3.0, as it is distributed, doesn't build on FreeBSD alpha (I run -current, but I think the same problems would exist for -stable). The following patch makes the build work for me - it runs ok with my matrox millenium II card (though my virtual consoles are permanently blank after X runs the first time, until next reboot - anyone have ideas on that?) It does 3 things -- it makes a prototype for a function that doesn't have one (I couldn't find a header file with this, so I just include it here -- seems ugly), it fixes a problem with system include files (needed an extra one) and it fixes some broken #ifdef'd code (the #endif is several lines past where it should be, making the file have systax errors (the function never finds a final closing '}'). - # diff xc/programs/Xserver/hw/xfree86/os-support/bsd/alpha_video.c xc.working/programs/Xserver/hw/xfree86/os-support/bsd/alpha_video.c 35a36,38 # ifdef __FreeBSD__ # include machine/sysarch.h # endif 38a42 53a58,59 axpDevice bsdGetAXP(void); 262a269 #endif 266d272 #endif - Is there a better way to submit patches like this? I've just subscribed to the devel list in the last 10 minutes :). Fred Clift ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: HW/SW cursor switching broken?
On Tue, 4 Mar 2003, Egbert Eich wrote: Keith Packard writes: Around 0 o'clock on Mar 4, Mark Vojkovich wrote: This is the core SW cursor not the ARGB SW cursor, though I haven't tried ARGB SW cursors (I forgot how to set one as the root cursor). $ XCURSOR_THEME=redglass XCURSOR_SIZE=256 xsetroot -cursor_name shuttle I guess I'll have to set a flag in the driver and ignore the SetCursorColors request when it's called while an ARGB cursor is displayed. The radeon driver already has such a flag. Perhaps we should put code into the hw cursor layer as well (in case a future driver forgets). Yes, it makes sense to have this code in the common layer. It seems like all we need to do is return from xf86RecolorCursor when the cursor is ARGB. I will see if this fixes the problem. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems compiling XFree86-4.3.0
On Mon, 3 Mar 2003, David Dawes wrote: Did you change any build options from their defaults? Try 'make WORLDOPTS= World' and see where it stops, or search your World log file for the first error. By default 'make World' will continue beyond errors. I've never liked that behaviour personally, but it's easy to override by setting WORLDOPTS to be empty as above. Cool! Thanks! I'm with you on not liking that behaviour... I assumed that since make We could change the default, and let those who like the current behaviour run 'make WORLDOPTS=-k'. Since the original reasons for this are less valid now (builds are much faster than they once were), and since it catches a lot of people out, maybe now is a good time to change the default. Would anyone object strongly to that? World ran to completion, there were no errors. Turned out that the error was that X assumes that cpp is in /usr/bin/cpp (which since I removed the RH gcc and friends and installed from source was in /usr/local/bin/cpp.) I made a link to /usr/local/bin/cpp in /usr/bin/cpp and everything ran fine! Maybe it'd be better to have cpp set to just 'cpp'? It used to have a full path because it used to be set to /lib/cpp, which isn't likely to be in anyone's search path. BTW, the /bin/cpp setting broke my RH 5.2 test build until I set it to /lib/cpp in host.def. I don't remember why it was changed from /lib/cpp, unless recent Linux distros don't have that link anymore. When building on x86_64 while bootstrapping our distro on that platform, X was looking for /lib/cpp, which ended up being /lib64/cpp on my installation at the time (which was indeed possibly broken). I made a small patch to change the default on Linux platforms to /usr/bin/cpp instead, which should work I believe on all Linux distros and architectures, the thought being that it would probably be more correct than relying on /lib/cpp legacy symlink being present. I submitted a patch which you committed to CVS on Dec 10th: Date: Tue, 10 Dec 2002 18:41:49 -0800 (PST) From: David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] List-Id: CVS commit messages from the XFree86 repository cvs-commit.XFree86.Org Subject: CVS Update: xc (branch: trunk) CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 02/12/10 18:41:48 Log message: 606. Change CppCmd on Linux to /usr/bin/cpp (#5514, Mike Harris). Modified files: xc/config/cf/: linux.cf Revision ChangesPath 3.196 +2 -2 xc/config/cf/linux.cf As you suggest above, I believe the more correct solution is to have it default to cpp instead, to have it default to wherever cpp happens to be in the user's path. The reasonable assumption being that cpp is in the user's path of course. ;o) -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: HW/SW cursor switching broken?
I'm forgetting this stuff... Is the caller of PushPixels supposed to add the drawable origin onto the x,y arguments of PushPixels or is PushPixels supposed to do that? It looks like the caller is supposed to add the origin before calling PushPixels. If I haven't misread this, then miDCPutBits is broken and that's the cause of my HW/SW switching problems. Offscreen pixmaps don't necessarily have zero origins and the rendering is getting clipped away. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 module compatibility?
Hi Guys, 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)? 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
Fixes needed to compile 4.3.0 on Solaris with Sun C
I needed to make the following changes in order to compile on Solaris 9
with an older version of the Sun C compilers (one without any C99 or
recent gcc-ish extensions). These changes should be compatible with all
compilers though.
1) Unneccessary use of C99/gcc varargs macros in makedepend.
The DBG_PRINT macro always uses three arguments, so specifying a variable
number seems unneccessary.
diff -ur 4.3.0/xc/config/makedepend/main.c solaris/xc/config/makedepend/main.c
--- 4.3.0/xc/config/makedepend/main.c Fri Jan 17 09:09:49 2003
+++ solaris/xc/config/makedepend/main.c Tue Mar 4 14:58:38 2003
@@ -57,9 +57,9 @@
/* #define DEBUG_DUMP */
#ifdef DEBUG_DUMP
-#define DBG_PRINT(args...) fprintf(args)
+#define DBG_PRINT(a,b,c) fprintf(a,b,c)
#else
-#define DBG_PRINT(args...) /* empty */
+#define DBG_PRINT(a,b,c) /* empty */
#endif
#define DASH_INC_PRE#include \
2) ICWrap.c derefences function pointers when it shouldn't when trying to
verify they are not NULL.
diff -ur 4.3.0/xc/lib/X11/ICWrap.c solaris/xc/lib/X11/ICWrap.c
--- 4.3.0/xc/lib/X11/ICWrap.c Mon Nov 25 06:04:53 2002
+++ solaris/xc/lib/X11/ICWrap.c Tue Mar 4 18:26:35 2003
@@ -395,9 +395,9 @@
XIC ic;
{
if (ic-core.im) {
- if (*ic-methods-utf8_reset)
+ if (ic-methods-utf8_reset)
return (*ic-methods-utf8_reset)(ic);
- else if (*ic-methods-mb_reset)
+ else if (ic-methods-mb_reset)
return (*ic-methods-mb_reset)(ic);
}
return (char *)NULL;
@@ -443,10 +443,10 @@
Status *status;
{
if (ic-core.im) {
- if (*ic-methods-utf8_lookup_string)
+ if (ic-methods-utf8_lookup_string)
return (*ic-methods-utf8_lookup_string) (ic, ev, buffer, nbytes,
keysym, status);
- else if (*ic-methods-mb_lookup_string)
+ else if (ic-methods-mb_lookup_string)
return (*ic-methods-mb_lookup_string) (ic, ev, buffer, nbytes,
keysym, status);
}
3) The -I. in xedit/lisp/Imakefile caused it to include the string.h in
that directory for #include string.h, resulting in undefined structure
errors. Removing it allowed the compile to finish sucessfully. (A better
solution would be to not have headers with the same names as standard
ANSI/POSIX standard includes.)
diff -ur 4.3.0/xc/programs/xedit/lisp/Imakefile
solaris/xc/programs/xedit/lisp/Imakefile
--- 4.3.0/xc/programs/xedit/lisp/Imakefile Fri Dec 13 20:41:13 2002
+++ solaris/xc/programs/xedit/lisp/ImakefileTue Mar 4 18:27:36 2003
@@ -112,7 +112,7 @@
DEFINES = -DLISP $(SHARED_DEFINES) -DLISPDIR='$(LISPDIR)' \
$(SNPRINTF_DEFS) $(SYS_DEFINES) $(SIGNAL_DEFINES)
DEPLIBS = mp re
- INCLUDES = -I. -Imp -Ire -I- $(MISC_INCLUDES)
+ INCLUDES = -Imp -Ire -I- $(MISC_INCLUDES)
LOCAL_LIBRARIES = -L. -llisp -Lmp -lmp -Lre -lre -lm $(DLLIB)
#ifdef IHaveSubdirs
4) Typo in the #else clause of #ifdef __GNUC__ in RenderLogo.c. Simply
appears to have never been tested with anything that's not gcc. (An
unrelated fix would be to check for C99 and if so, use __func__.)
diff -ur 4.3.0/xc/programs/xlogo/RenderLogo.c solaris/xc/programs/xlogo/RenderLogo.c
--- 4.3.0/xc/programs/xlogo/RenderLogo.cSat Oct 19 12:15:32 2002
+++ solaris/xc/programs/xlogo/RenderLogo.c Tue Mar 4 18:30:03 2003
@@ -156,7 +156,7 @@
#ifdef __GNUC__
fprintf(stderr, %s: intersection is off by: %f\n, __FUNCTION__, fabs(check -
intersection-x));
#else
- fprintf(stderr, intersect: intersection is off by %f\n, fabs(check -
instersection-x));
+ fprintf(stderr, intersect: intersection is off by %f\n, fabs(check -
intersection-x));
#endif
}
}
-Alan Coopersmith- [EMAIL PROTECTED]
Sun Microsystems, Inc. - Sun Software Group
Quality, Integration, Customer Success (QICS)
Platform Globalization Engin. - X11 Engineering
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Feigning erudition, Kendall Bennett wrote: % Hi Guys, % % 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). Hmm. I installed 4.3.0 on a crash test dummy at work today. I had the mga_hal.o module from Matrox for 4.2.mumble. Copied it into place, started X, and it seemed to load without incident - no untoward messages in the log files and neither the monitor nor the video card went up in smoke. ;-) More generally, where might I might information on determining binary compatibility, or lack thereof, between module version and XFree releases? Kurt -- With a gentleman I try to be a gentleman and a half, and with a fraud I try to be a fraud and a half. -- Otto von Bismark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Kurt Wall [EMAIL PROTECTED] wrote: Hmm. I installed 4.3.0 on a crash test dummy at work today. I had the mga_hal.o module from Matrox for 4.2.mumble. Copied it into place, started X, and it seemed to load without incident - no untoward messages in the log files and neither the monitor nor the video card went up in smoke. ;-) Interesting. It is possible that the binary compatibility is for forward releases only. ie: 4.3.0 can run 4.2.x and 4.1.x etc binaries, but 4.1.x will not allow loading of future driver binaries 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
