xc/programs/mkcfm/cidchar.c doesn't compile
xc/programs/mkcfm/cidchar.c doesn't compile Oddly this is a link to xc/lib/font/Type1/cidchar.c which *does* compile gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I../../lib/font/Type1 -I../../lib/font/include -I../../programs/Xserver/include -I../../exports/include-Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DBUILDCID -DCID_ALL_CHARS-c -o cidchar.o cidchar.c cidchar.c: In function `CIDGetGlyphInfo': cidchar.c:122: structure has no member named `CIDsize' cidchar.c:191: structure has no member named `CIDsize' cidchar.c:268: structure has no member named `CIDsize' cidchar.c:306: structure has no member named `CIDsize' cidchar.c:348: structure has no member named `CIDsize' cidchar.c:360: structure has no member named `CIDsize' make: *** [cidchar.o] Error 1 -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: _X11TransSocketUNIXConnect: Can't connect: errno = 111
On Wed, 26 Oct 2005, Stefan Strobl wrote: Andrew C Aitchison wrote: On Tue, 25 Oct 2005, Stefan Strobl wrote: There are some more messages which I'm not able to capture. Logging to a file didn't work. After restarting the file's empty... How hard is the restart - power button, or just ctrl-alt-delete (or ctrl-alt-f1, ctrl-alt-delete) ? I have to power cycle the machine... In that case the following is less likely to help. When working with lockups I sometimes set a 5 minute cron job to sync the disks: 0,10,20,30,40,50 * * * * /bin/sync 5,15,25,35,45,55 * * * * /bin/sync then when it locks up I wait five minutes before pressing the power button. This often gives the machine a chance to write the log to disk. I don't quite understand? Sometimes the graphics card is locked up, but the cpu is still running; it is just that you can't see what it is doing. If the Xserver is chewing cycles you might not have a keyboard either. In these cases, syncing the disk can flush buffers so that the log file does contain useful info on reboot. You did redirect stdin *and* stderr ( in bash) to the logfile ? I can't remember now, does XF_SVGA have options to increase its verbosity ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: _X11TransSocketUNIXConnect: Can't connect: errno = 111
On Tue, 25 Oct 2005, Stefan Strobl wrote: Loic Grenie wrote: You should have a XFree86 binary installed somewhere (/usr/X11R6/bin usually) by make install. Just run the binary, it should work. To come back to a text terminal, hit Ctrl-Alt-F1. Lo�c Greni� Thanks. I've no binary called XFree86. When executing XF86_SVGA, that's the server I want to use, Is this XFree86 v3 or v4 ? I think XF86_SVGA went out with v3, which was about 6 years ago (and more like 8 for developers). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Problems with xf86Globals.c
I'm not sure why this change from January to xc/programs/Xserver/hw/xfree86/common/xf86Globals.c is only biting now but: xf86Globals.c:236: warning: missing braces around initializer xf86Globals.c:236: warning: (near initialization for `xf86Info.grabInfo') xf86Globals.c:237: warning: braces around scalar initializer xf86Globals.c:237: warning: (near initialization for `xf86Info.grabInfo.override') xf86Globals.c:237: warning: excess elements in scalar initializer xf86Globals.c:237: warning: (near initialization for `xf86Info.grabInfo.override') xf86Globals.c:237: warning: excess elements in scalar initializer xf86Globals.c:237: warning: (near initialization for `xf86Info.grabInfo.override') xf86Globals.c:237: warning: excess elements in scalar initializer xf86Globals.c:237: warning: (near initialization for `xf86Info.grabInfo.override') xf86Globals.c:238: warning: initialization makes integer from pointer without a cast xf86Globals.c:239: warning: initialization makes integer from pointer without a cast xf86Globals.c:241: incompatible types in initialization xf86Globals.c:241: initializer element is not constant xf86Globals.c:241: (near initialization for `xf86Info.grabInfo.server.grabstate') xf86Globals.c:243: initializer element is not constant xf86Globals.c:243: (near initialization for `xf86Info.grabInfo.server') xf86Globals.c:243: initializer element is not constant xf86Globals.c:243: (near initialization for `xf86Info.grabInfo') This is Red Hat 9, gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5) -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, 8 Feb 2005, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? How often does the Xserver / DRM binary interface change - is it viable to just use the DRM in the running kernel ? I suppose this is really a question for one of the DRM lists but, is it a forlorn hope that the DRM could have a static binary interface to either the kernel or the X server ? (I guess that a moving kernel puts the former outside the control of the DRM project ?) -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
drm uses revpath before we had built it
With the i810 kernel module build fixes, a make World fails with: make[7]: Entering directory `/home/XFree86/4.2/std/xc/programs/Xserver/hw/xfree86/os-support/linux/drm' + mkdir -p kernel_source /bin/sh: line 1: ../../../../../../../config/util/revpath: No such file or directory make[7]: *** [includes] Error 1 -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRI on i810
David Dawes [EMAIL PROTECTED]: Has anyone tried DRI on an i810 with the current tree? I get a ring buffer lockup almost immediately after running glxgears. This is with the current i810 DRM module built and loaded against an otherwise stock 2.4.24 kernel. Can you remind me how to build the i810 DRM module ? makefile.linux seems to have disappeared. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: How do I debug modules/drivers symbolically in the X server?
On Fri, 24 Sep 2004, Barry Scott wrote: I'm trying to debug a problem with the Unichrome VIA driver in XFree86 4.4.0. How do you debug in the X server given that loadmod.c that seems to be loading all the code is not using mechanisms that allow gdb to know where the code is? So far I've patched in a call to add messages to the XFree86 log detailing the address that each module is loaded at. Surely there is an easier way? There have been several patches to add xfree86 module support to gdb, and talk of these patches going back into the gdb code-base. Googling XFree86 module gdb found me this patch http://www.logix.cz/michal/devel/gdb-xfreemod/ and this reminder from http://www.mail-archive.com/[EMAIL PROTECTED]/msg05907.html With the special gdb you need to explicitly load the modules in order to get a backtrace. Ie, before you get the backtrace enter module /usr/X11R6/lib/modules at the gdb prompt to indicate where to get the modules from. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: UseFBDev makes X-display in several wide bars, each 110 degree rotated, unusable
On Thu, 16 Sep 2004, [ISO-8859-2] Martin MOKREJ© wrote: Martin MOKREJ© wrote: Actually, I didn't know earlier but the radeon should not continue but make X rather die as I have AGP 9200 card, and that's actually the reason why I have to use ati as driver. The naming is bad, but empirically I have figured out which drier works and aslo gives DRI. The credit goes to Philipp Klaus Krause from dri-users list: radeon is the driver for the Radeon 7000 series cards. ati is the one for Radeon 8500 to 9200. Last time I looked, ati was a wrapper driver which used one of the drivers mach64, r128 or radeon as appropriate, and radeon was appropriate for all Radeon cards. Has someone been playing around ? Or have you got different versions of the ati and radeon drivers ? There is also the drver from ATI, I've forgotten what that is called. Come to thing of it, the XFree86 radeon driver only support hardware 3D/GL/DRI for older Radeon cards; maybe that is what Philipp Klaus Krause meant ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
tinyx breaks build on RedHat 6.2
tinyx breaks build on RedHat 6.2 / egcs-1.1.2 / glibc-2.1.3 many .c files break in /usr/include/sys/io.h because of the combination of the inline derective and the -ansi compiler option. sis530/sis.h has the definition #define inline __inline__ This definiton would appear to be needed more widely throughout tinyx Any ideas how more modern compilers/libcs avoid this problem ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How the screen to be Rotate 90deg
On Wed, 14 Jul 2004 11:52:42 +0530, NaggarajaVignesh.R [EMAIL PROTECTED] wrote: Hi Iam trying to Rotate the Screen 90 in Red Hat Linux 9.0 with System Configuration intel 845 graphics card .The error msg is X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 156 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 12 Current serial number in output stream: 12 (In spite of the name) RANDR does not do rotation (at least not in XFree86 the people who wrote it have moved to Xorg, so it might do rotation there). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs compile failed
On Mon, 28 Jun 2004, Andrew C Aitchison wrote: CVS compile works for me since this change revision 3.479 date: 2004/06/23 16:58:39; author: dawes; state: Exp; lines: +2 -2 Turn XItsyServer off by default (it doesn't build). in xc/config/cf/xfree86.cf You probably need to do a make World (or at least make Makefiles) in the top level to get this change to take effect. ... However make install fails with install -c -m 0444 SecurityPolicy /usr/X11R6/lib/X11/xserver/SecurityPolicy install: cannot stat `SecurityPolicy': No such file or directory make[5]: *** [install] Error 1 make[5]: Leaving directory `/home/XFree86/4.4/std/xc/programs/Xserver/Xext/tiny' Work-around appears to be make -k install -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Adding DMX to XFree86
On Tue, 22 Jun 2004, Kevin E Martin wrote: We would like to include DMX in the next XFree86 release. 7. Add DMX and GLX Proxy support to Xinerama 9. Add protocol and structures to support GLX Proxy (from SGI) Does GLX Proxy allow hardware accelerated GLX ? Does it allow hardware accelerated GLX from remote machines independent of DMX ? If so GLX Proxy seems desireable on its own account. (I have nothing against DMX, just remote GLX is something I've wished for for nearly a decade). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs compile failed
On Wed, 23 Jun 2004, Jeff Chua wrote: Just downloaded the lastest cvs. Failed to compile. The error lines before the ones Jeff quoted seem more illuminating: In file included from itsy.c:70: itsy.h:27:27: linux/itsy_fb.h: No such file or directory itsy.h:28:27: linux/itsy_ts.h: No such file or directory itsy.h:29:32: linux/itsy_buttons.h: No such file or directory itsy.h:30:32: linux/itsy_session.h: No such file or directory kbd.c also has missing files kbd.c:25:21: kkeymap.h: No such file or directory kbd.c:27:32: linux/itsy_buttons.h: No such file or directory -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i2c bus and/or DDC control
On Thu, 29 Apr 2004, Ben Guthro wrote: I'm looking into writing an app to be able to control display controls via DDC - DDC2ci, or SoftDDC I've been going through the 4.4.0 sourcebase, and while I have seen numerous references on how to implement DDC control at the driver level over the i2c bus. Is there an API, or server extension which exposes this interface? Mac OSX 10.3 exposes the I2C bus at the user level via a IOI2CSendRequest command. Is there an equivalent for X? Jablonka Ivan [EMAIL PROTECTED] was asking about ddc/ci recently. There is as yet no intereface in XFree86 to use DDC for control (just the XFree86_DDC_EDID1_RAWDATA X property which makes the EDID information available). Some linux kernel frame-buffer modules may make DDC available through the kernel I2C machanisms. Do you have DDC2ci specs ? I'd be interested in seeing what we would need to put into a control API. (Google shows no hits for SoftDDC). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: function definition isn't a prototype
On Fri, 2 Apr 2004, Terry R. Friedrichsen wrote: From a March 31 CVS update, there are 2714 of the above warnings in a make World when compiling under FreeBSD 5.2 on an Alpha. With some guidance from the committers, I'd like to take on the task of eliminating the vast majority of these. I'll provide context diffs and submit them to the bug tracker as time permits, but I'd like to know whe- ther you feel that the declarations in question should be wrapped in some- thing like #ifdef __STDC__ / #endif or not first. I'm not a committer, just someone who has been around long enough to remember the discussions about ansifying the code. I don't think we need #ifdef __STDC__ or similar. The ansification work is progressing very slowly because we need to be sure that we don't change the types of any arguements when we do this - remember that the default type promotions rules changed between KR and ANSI C. This means that the could be binary incompatibilities in the interfaces we we do this with a dummy script, rather than a thinking brain. Thomas Dickey has done bits in the past, and has email suggestions about how to verify that binary compatibility isn't broken. Thanks for offering to help. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Tue, 2 Mar 2004, Alan Hourihane wrote: I mentioned in a reply to Alex, that maybe the ScreenLayout section should use Monitor's rather than Screens. I think that should fix the orientation issues, as the ScreenLayout is really describing the monitor positions. I didn't spot this the first time around. At present there is no need for two monitor sections when you have two identical monitors, as each Screen can use the same Monitor. Don't know whether that change is important. So you'd only use the modes for the second monitor that is described for the primary monitor ? I'm not keen on that. Some people will have two very different monitors, and many of the Matrox cards support more modes (RAMdac bandwidth limits) on one head than the other. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
broken xf86PciInfo.h and xf86cfg/config.h
The licence updates to xf86PciInfo.h haven't patched cleanly, and are mis-commented, breaking the build. The attached patch fixes this. -- xc/programs/Xserver/hw/xfree86/xf86cfg/config.h is also broken; it includes the lines: config.h #include unistd.h === #ifdef sun #undef index #undef rindex #include strings.h #endif #include unistd.h 1.20 I'm not clear which version we wish to keep. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna Index: xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h === RCS file: /home/CVS/XFree86/xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h,v retrieving revision 1.157 diff -u -r1.157 xf86PciInfo.h --- xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h 2004/02/13 23:58:38 1.157 +++ xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h 2004/02/15 08:46:04 @@ -2,7 +2,7 @@ /* * Copyright (c) 1995-2003 by The XFree86 Project, Inc. - */ + * * All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining @@ -46,6 +46,7 @@ * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE * OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ /* * This file contains macros for the PCI Vendor and Device IDs for video
Re: [Linux-fbdev-devel] Re: [forum] Re: Announcement: Modification to the base XFree86(TM) license.
On Sat, Jan 31, 2004 at 09:10:22AM +, Andrew C Aitchison wrote:
On Fri, 30 Jan 2004, Sven Luther wrote:
Yeah, that would be rather problematic, but anyway, most of the things
move from the XFree86 code to fbdev code, and most often, it is not code
that is copied, but the register information and such. It is always
easier to get specs if you are working for XFree86 than if you plan to
do some kernel driver work.
On Sat, 31 Jan 2004, Benjamin Herrenschmidt wrote:
The fact that it is mostly a one way is mostly due to the fact that the
main problem here is seeking for HW informations.
For several years the mga fb kernel driver has supported dual head and/or
dvi on cards which aren't supported by the XFree86 driver (unless you
use the mga_hal). I've wanted to use kernel code to add this support to
XFree86, but been put off by the licence problem.
On Sat, 31 Jan 2004, Sven Luther wrote:
And, have you asked the mgafb driver author about this ?
You can hardly complain about lack of back traffic if you didn't ask him
about it, and if you did, it would be interesting to this discussion to
know what the problems where.
On Sat, Jan 31, 2004 at 01:06:23PM +, Andrew C Aitchison wrote:
The Author ?
This is open source code; there may be 27 authors of the relevant file.
In XFree86 code I wouldn't know how to find the author of a file without
looking at that file. My {limited ,mis}understanding of clean room coding
makes me wary of reading any source unless I know that its licence will
allow me to do what I wish.
On Mon, 2 Feb 2004, Sven Luther wrote:
This is not acceptable. You are making wild accusations, and didn't even
try to contact the relevant people. To my knowledge, Petr is the sole
author of matroxfb, and there should not have been any problem in at
least asking him about this.
I didn't intend to make *any* accusations, and don't understand what
accusations I'm supposed to have made.
I clearly have to explain my starting position more clearly;
it is probably wrong, and almost certainly the cause of most of the
confusion, however it is how I came into this arguement, and maybe seeing
how I'm thinking will let you see that I wasn't making accusations.
My understanding of copyright/patents/plagarism (I'm vague and confused
about which this covers) is that merely by reading your document,
I am allowing the possibility that I may use that information in something
which I later write.
This is the principle behind cleanroom development, see
http://en.wikipedia.org/wiki/Cleanroom,
meaning 2.
If my licence to use your document doesn't allow me to do what I wish,
it is therefore better for me not to read your document.
My understanding about fbdev was that it was GPL-licenced, and that
it is *not* OK to incorporate GPL-ed code into XFree86.
Since I can't read the source code, I can't see who owns the bit I'm
interested in and can't therefore ask permission to use it under a
different licence.
I merely wished to point out that the GPL-licence *had* affected my
decision not to copy anything from fdbdev into XFree86.
Call me lazy, mis-informed, confused and paranoid, but I resent the
suggestion that I've been making accusations, wild or tame.
OK. So I've probably been paranoid and lazy, but if the fbdev licence
had been compatible with the XFree86 one, I would have done the work.
As it is the bar was raised high enough to stop me.
Yeah, whatever, but with you asking that the fbdev drivers change their
licence, it is the same thing as the GPL zealots not liking the new
XFree86 licence.
The way to solve this is by cooperation, not by staying aloft and
pointing the finger to the opposite side.
I didn't intend to ask that fbdev change their licence (although I wish
they would). I merely intended to point out that, however much the fault
was mine, the perception of the licence conflict had blocked transfer
from fbdev to XFree86.
Since Sven and Benjamin both suggested that transfer from fbdev to
XFree86 wasn't important, I thought it reasonable to relate my
experience showing that transfer in that direction was desirable and
that the GPL-licence was a hinderance.
I also realize that I have a habit of using complex and precise English.
As many people in this discussion are not native English speakers,
that is not smart, and may be why some of my intended meaning has
not got through. I apologize for this.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding dual headed machines with two keyboards and two mice
On Fri, 16 Jan 2004, Mark Cuss wrote: Okay - thanks! I did find the link you sent, but was wondering if this was supported in the new 4.4.0 release... Is there support planned in a future release? You can run a single X server with two screens, two mice (mice, not pointers/cursors) and (I think) two keyboards. You could run two X servers each with a screen keyboard and mouse, the problem is that normally there is only a single console, and only one *active* virtual terminal (I'm thinking Linux, but this is true for most if not all supported OSes). Try this; it works but you have to switch VTs with CtlAltFn to see both X servers. As I see it this is an OS issue, not an XFree86 issue - XFree86 turns a text head into a graphics head. If the OS only provides one text console at a time, XFree86 only gives you one graphics head at a time. (OK maybe it would be possible for an Xserver not to use a VT). I understand that 2.5.x kernels can support multiple text consoles, and I understand that in this case two X head can be done. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Mozilla assumes unassigned chars in iso10646-1 FreeType fonts as assigned with XF4.4.0 trunk
On Fri, 12 Dec 2003, Roland Mainz wrote: Hi! Is anyone else seeing the problem that Mozilla now renders glyphs in iso10646-1 fonts which are not assigned (normally Mozilla scans iso10646-1 encoded fonts for valid glyphs via looking at non-zero width metrics and puts those glyphs into it's internal CCMap), e.g. the glyph 0 is rendered. I am getting lots of these little square boxes when viewing http://www.google.co.il/search?as_q=mozillanum=100hl=iwie=UTF-8oe=UTF-8btnG=%D7%97%D7%99%D7%A4%D7%95%D7%A9+%D7%91%D7%92%D7%95%D7%92%D7%9Cas_epq=as_oq=as_eq=lr=as_ft=ias_filetype=as_qdr=allas_occt=anyas_dt=ias_sitesearch=? on SuSE 8.2 + XF4.0.0 todays CVS trunk (original Xfree86 shipped with SuSE 8.2 is OK). I'm not seeing little square boxes, and the page looks ok to my uninitiated eye. I've seen fonts which have little square boxes rather than gylphs with zero-width metrics. If you have one of these, the algorithm you describe wont help :-( -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Aiptek driver doesn't build on Red Hat 6.2
Fixing bug 940 breaks the build on Red Hat 6.2. I believe that the aiptek driver should only work with LINUX_INPUT, in which case, the patch I've submitted in bug 972 will stop the attempt to build aiptek on systems without LINUX_INPUT. (Please use the second patch - the first one isn't good enough). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: FW: RE: [Bug 537] wacom usb tablet uses wrong screen borders
On Tue, 25 Nov 2003, Ping Cheng wrote: For example, my application needs to get the tablet's model from the driver. But the driver only knows the model after it communicates with the tablet. So, the model can not be assigned into an option in the config file. Basically, I don't have problem to sent data to the driver from client. I use xfWcmDevChangeControl(), which is assigned as local's control_proc to send data to the driver. I have problem to pass data from driver back to the app. That's why I let driver write to a file so the app can read from there. Sorry, I should have suggested this earlier. The driver can set window properties via xf86RegisterRootWindowProperty() (xc/programs/Xserver/hw/xfree86/common/xf86Helper.c) Then any client can read these properties from the server - use the command-line app xprop, or see how it does it. I'm not sure how well static property names will represent information about zero, one or more tablets - perhaps you need properties like: WACOM_TABLET_COUNT WACOM_TABLET0_MODEL ... WACOM_TABLET1_MODEL ... -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 2D Acceleration not used using ATI Rage Mobility P/M AGP 2x
On Mon, 17 Nov 2003, Salvio wrote: On Sun, 16 Nov 2003, Salvio wrote: I have attached the latest config file and log. What happens if you disable 3D acceleration by commenting out Load DRI in the Module section ? Section Module Load dbe Load extmod Load fbdevhw Load glx Load record Load freetype Load type1 #Load dri EndSection 3D acceleration on the Mach64 isn't standard: I'm not sure that anyone has tested that 2D and 3D accleration work well together. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Fix for dri_util.o
The attached patch fixes the dri_util build failure: ../../../../../../lib/GL/dri/dri_util.c:1322: `PFNGLXGETMSCRATEOMLPROC' undeclared (first use in this function) Removing the explict inclusion of inttypes.h means that some of the includes need to be reordered. PFNGLXGETMSCRATEOMLPROC is defined in xc/extras/Mesa/include/GL/glxext.h Feel free to use a different reordering; I've only tested this on RedHat 6.2 -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna Index: xc/lib/GL/dri/dri_util.c === RCS file: /home/CVS/XFree86/xc/lib/GL/dri/dri_util.c,v retrieving revision 1.11 diff -u -r1.11 dri_util.c --- xc/lib/GL/dri/dri_util.c2003/11/13 17:22:49 1.11 +++ xc/lib/GL/dri/dri_util.c2003/11/14 09:24:35 @@ -25,10 +25,10 @@ #include Xext.h #include extutil.h #include stdio.h +#include dri_util.h #include glxclient.h #include xf86dri.h #include sarea.h -#include dri_util.h /* forward declarations */
Re: Capturing events from the root window
On Thu, 30 Oct 2003, Gerhard W. Gruber wrote: Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. I believe that the RECORD extension is what people use for that sort of thing. xc/doc/hardcopy/Xext/record.PS.gz xc/doc/hardcopy/Xext/recordlib.PS.gz xc/doc/specs/Xext/record.ms xc/doc/specs/Xext/recordlib.ms Don't know whether it will help you at all. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Detecting Monitor mode from AutoConfig
On Mon, 6 Oct 2003, Kirk Haderlie wrote: Is there an interface available to enumerate the video modes supported by a monitor? It would be nice to get this information for use in auto config. We have a dual head configuration with one monitor which supports up to 1024 x 768 and the second up to 800 x 600. The problem is that X tries to drive the second monitor at 1024 x 768. If I configure XF86 manually I can get the first to run 1024 X 768 and the second in 800 x 600. I want to customize the monitor sections of auto config. I have already modified auto config to support multiply heads but now would like to implement custom monitor configurations. Any help or suggestions would be appreciated. In principle the full DDC information is available from each monitor, but in practice for most dual-head cards we don't kow how to ask for the information about both heads. If this is a laptop with a builtin screen and an external monitor socket, we don't even have a consensus as to whether the builtin screen has DDC info. Once the server has started, if you are *not* using Xinerama or similar methods of making the displays appear as one, the DDC data is available as a root window property; usually XFree86_DDC_EDID1_RAWDATA, which can be printed out with: xprop -display $DISPLAY -root 0x XFree86_DDC_EDID1_RAWDATA -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mulitple pointers
On Tue, 7 Oct 2003, Grant Wallace wrote: Earlier this year there was a mail thread about multiple pointers. I'm wondering if there is any new information on this topic. We would like to have a collaborative desktop on a display wall where multiple people can work simultaneously. In particular it would be nice to have multiple top level windows (one per cursor) where that cusror's keyboard and mouse events are sent. Earlier it was suggested that this should be handled by the collaborative software. But in our case we'd rather not write specific software, but rather let people run their current applications unmodified on the desktop. Are there any extensions or suggestions on how to develop a scenario like this? This doesn't really fit into the design philosophy of X11. I don't know anything about the code at window focus level, or the window management protocols, so the followinbg suggestion might not be smart: IIRC X will happy support many non-core pointer devices; so write a window manager which listens to all the non-core pointers and does with them what you want. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Debugging XFree86 on a single machine
On Wed, 1 Oct 2003, Kirk Haderlie wrote: Is it possible to debug XFree86 using a dual monitor setup on a single machine. I tried using -keeptty but this doesn't do what I would expect. Can X be run on one monitor and a debug console on the other? You need two video cards (as Andrew Bevitt mentioned). You must make sure that the server under test doesn't grab the keyboard or mouse from the debug console; giving it dummy devices with the void input device driver (you could use a second mouse but I've never got a second keyboard to work with 2.4.small kernels). All in all, telnet/ssh from a second machine is usually less hassle. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pkg-config support for libs
On Mon, 22 Sep 2003, Mike A. Harris wrote: We move the XFree86 supplied .pc files into /usr/lib/pkgconfig/ where the default pkgconfig configuration can find them. A better fix would be either making XFree86 install them into /usr/lib/pkg-config by default, or making the default configuration file for pkgconfig contain the X11 pkgconfig directory. Thoughts? (Under most normal circumstances) XFree86 tries not to install anything outside of /usr/X11R6/ I'm not clear whether it should be the job of the XFree86 installer, or whoever packages it for a distribution to put files into /usr/lib/pkgconfig ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Linking Xprt, Xnest and Xvfb fails - undefined reference to `xf86Msg'
Change 423. Add a writing of some Xserver XKB module error messages into a servers log file (Ivan Pascal) seems to have broken linking Xprt, Xnest and Xvfb: gcc -o Xprt -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib Xprint/ddxInit.o Xprint/miinitext.o Xprint/dpmsstubs.o dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a Xprint/libprinter.aXprint/raster/libraster.a Xprint/pcl/libpcl.a Xprint/ps/libps.a mfb/libmfb.a cfb/libcfb.a cfb32/libcfb32.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a Xext/libext.a dbe/libdbe.a record/librecord.a GL/glx/libglx.a GL/mesa/GLcore/libGLcore.a XTrap/libxtrap.a os/libcwrapper.o ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -lm -Wl,-rpath-link,../../exports/lib xkb/libxkb.a(xkbInit.o): In function `XkbInitDevice': xkbInit.o(.text+0xb92): undefined reference to `xf86Msg' xkbInit.o(.text+0xb9e): undefined reference to `xf86Msg' xkbInit.o(.text+0xc10): undefined reference to `xf86Msg' xkb/libxkb.a(xkbInit.o): In function `XkbInitKeyboardDeviceStruct': xkbInit.o(.text+0x141d): undefined reference to `xf86Msg' xkb/libxkb.a(xkbInit.o): In function `XkbProcessArguments': xkbInit.o(.text+0x18de): undefined reference to `xf86Msg' xkb/libxkb.a(ddxLoad.o)(.text+0x977): more undefined references to `xf86Msg' follow collect2: ld returned 1 exit status make[4]: *** [Xprt] Error 1 -- gcc -o Xnest -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib hw/xnest/miinitext.o dix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a hw/xnest/libxnest.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a hw/xnest/libxnest.a Xext/libext.a dbe/libdbe.a record/librecord.a GL/glx/libglx.a GL/mesa/GLcore/libGLcore.a XTrap/libxtrap.a os/libcwrapper.o ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -L../../exports/lib -lXext -lX11 -lz -lm -Wl,-rpath-link,../../exports/lib xkb/libxkb.a(xkbInit.o): In function `XkbInitDevice': xkbInit.o(.text+0xb92): undefined reference to `xf86Msg' xkbInit.o(.text+0xb9e): undefined reference to `xf86Msg' xkbInit.o(.text+0xc10): undefined reference to `xf86Msg' xkb/libxkb.a(xkbInit.o): In function `XkbInitKeyboardDeviceStruct': xkbInit.o(.text+0x141d): undefined reference to `xf86Msg' xkb/libxkb.a(xkbInit.o): In function `XkbProcessArguments': xkbInit.o(.text+0x18de): undefined reference to `xf86Msg' xkb/libxkb.a(ddxLoad.o)(.text+0x977): more undefined references to `xf86Msg' follow collect2: ld returned 1 exit status make[4]: *** [Xnest] Error 1 -- gcc -o Xvfb -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib hw/vfb/stubs.o hw/vfb/miinitext.o hw/vfb/dpmsstubs.odix/libdix.a os/libos.a ../../exports/lib/libXau.a ../../exports/lib/libXdmcp.a hw/vfb/libvfb.a fb/libfb.a mfb/libmfb.a dix/libxpstubs.a mi/libmi.a Xext/libexts.a xkb/libxkb.a Xi/libxinput.a lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a randr/librandr.a render/librender.a mi/libmi.a Xext/libext.a dbe/libdbe.a record/librecord.a GL/glx/libglx.a GL/mesa/GLcore/libGLcore.a XTrap/libxtrap.a os/libcwrapper.o ../../lib/font/libXfont.a -lfreetype dix/libxpstubs.a -lz -lm -Wl,-rpath-link,../../exports/lib xkb/libxkb.a(xkbInit.o): In function `XkbInitDevice': xkbInit.o(.text+0xb92): undefined reference to `xf86Msg' xkbInit.o(.text+0xb9e): undefined reference to `xf86Msg' xkbInit.o(.text+0xc10): undefined reference to `xf86Msg' xkb/libxkb.a(xkbInit.o): In function `XkbInitKeyboardDeviceStruct': xkbInit.o(.text+0x141d): undefined reference to `xf86Msg' xkb/libxkb.a(xkbInit.o): In function `XkbProcessArguments': xkbInit.o(.text+0x18de): undefined reference to `xf86Msg' xkb/libxkb.a(ddxLoad.o)(.text+0x977): more undefined references to `xf86Msg' follow collect2: ld returned 1 exit status make[4]: *** [Xvfb] Error 1 -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
Re: DPI with multiple heads and virtual desktops
On Wed, 20 Aug 2003, Alex Deucher wrote: this is a semi-fix, but it still does not deal with monitors that have different DPI. Perhaps this is something that needs to be looked at for xfree 5. Almost certainly not before XFree86 v5. Even then I don't think a solution to your problem is actually possible for Xinerama; I don't know whether it would be for MergedFB. Xinerama *hides* the fact that there are two heads, so there is no way for the app to be told a different DPI debending which head it is currently on - what should it be told if it is on both ? Are you sure you actually want the problem solved anyway ? We have a laptop with a 125dpi screen and a lecture room projector with about 8dpi. If I were to make it run a two screen desktop, and my slide viewer honoured the true screen DPI, on one screen 12pt letters would be 20 pixels tall, and on the other they would be about one pixel. IMO either you want the same DPI on both screens (fake whatever value you want with DisplaySize or X -dpi NN) or you want two non-xinerama heads - display:0.0 and display:0.1, which allows apps on each head to get the right answer for that screen*, and stops the DPI changes which would occur if the window was allowed to move between screens. * Ignoring ctlalt+/- mode changes. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiliconMotion Rotation
On Mon, 18 Aug 2003, Chris Edgington wrote: The siliconmotion driver has its own internal rotation option. It appears that this works by enabling ShadowFB, then using the hardware rotation capabilities to rotate-blt the changed areas. This worked fine with XF 4.2.0. However, with the same hardware, this is broken with XF 4.3.0. I diffed the smi_driver.c code between those versions and nothing seems to have been changed in the driver code that would have affected rotation. I have heard that the addition of the RandR (Rotate and Resize) extension into 4.3 broke some drivers which already did rotation. One thing that is not clear to me is how the X system in general is notified of the rotated resolution. In the driver, when rotation is enabled, the only apparent swapping of width and height that goes to anything outside of the driver is the initialization of the framebuffer layer's ScreenInit. Is this enough to communicate the rotated resolution? If I heard correctly, one of the features of RandR is that it allows this sort of notification. Unfortunately this area suffered in the political fight which happened around the time of the 4.3 release. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: old Mach32 and Mach64 servers
On Wed, 13 Aug 2003 [EMAIL PROTECTED] wrote: Can anyone tell me how good a job the old Mach32 and Mach64 servers did of taking advantage of the hardware capabilities of their respective silicon engines? Put another way, were there capabilities in the silicon that we did not use? If there are transistors not pulling their weight, are docs available to remedy the situation should one be so inclined to do so? I don't have access to the docs, but there are many chipsets with the mach64 core, going from (iirc) isa to agp (or at least gart). Also iirc it is used on laptop chipsets released after the radeon (ATI Mobility M1 springs to mind, but I can't easily confirm). Since these are based on the Mach64 they all use the mach64 driver although there possess very different features. There is a GATOS project to add 3D to those mach64 chips which support 3D; it has never been merged into the XFree86 driver. Xv may or may not have made it into the mach64 driver too. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
CVS service on cvsup.xfree86.org not available
cvsup.xfree86.org isn't providing a CVS service today. anoncvs.xfree86.org is, so this isn't urgent. Is this a technical problem, or is cvsup.xfree86.org being phased out ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Hardware overlays (8+24?) on Intel i830
I see from http://www.xig.com/Pages/PrReleases/PRMay03-830-O'lays.pdf that hardware overlays (possibly similar to what we currently do in the mga and glint drivers) are possible on the Intel i830 chipset. Does anyone know anything more, or is anyone actually working on adding support to our drivers ? If anyone with a suitable machine is interested in testing for me, and I can get chip-level details, I *might* be interested in writing the code myself. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
On Thu, 24 Jul 2003, Egbert Eich wrote: Can we just declare that inet and inet6 both match tcp ? The way the code is currently written aliases like tcp alias to exactly one transport type. There is no fallback mechanism. The easiest way would be to alias tcp to inet instead of inet6. Agreed. That will at least give us backwards compatibility. inet6 is new; people using it can cope with asking for it explicitly. Or somebody designes a fallback mechansim. When we release XFree86 4.4 or 5.0 we need machinename:display to work on any appropriate transport protocol (probably tcp/ as it is now) and tcp/machinename:display to work for inet/ and inet6/ -nolisten tcp should block inet and inet6. --- Aside: Which operating systems are shipping with IPv6 enabled by default ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IPv6 problems on Linux
On Wed, 23 Jul 2003, Egbert Eich wrote: I've made the patch below which takes care of the problem for me. make[3]: Entering directory `/home/XFree86/4.2/std/xc/lib/ICE' rm -f transport.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -I../../lib/xtrans -DUNIXCONN -DTCPCONN -DHAS_STICKY_DIR_BIT -DHAS_FCHOWN -DIPv6 -DICE_t -DTRANS_CLIENT -DTRANS_SERVER-fPIC transport.c In file included from transport.c:85: ../../lib/xtrans/Xtrans.c: In function `_IceTransMakeAllCOTSServerListeners': ../../lib/xtrans/Xtrans.c:1041: `Bool' undeclared (first use in this function) ../../lib/xtrans/Xtrans.c:1041: (Each undeclared identifier is reported only once ../../lib/xtrans/Xtrans.c:1041: for each function it appears in.) ../../lib/xtrans/Xtrans.c:1041: parse error before ipv6_succ ../../lib/xtrans/Xtrans.c:1074: `ipv6_succ' undeclared (first use in this function) ../../lib/xtrans/Xtrans.c:1112: `TRUE' undeclared (first use in this function) make[3]: *** [transport.o] Error 1 Should that be BOOL, TRUE (and FALSE) as defined I don't know where (or Bool, True and False as defiend in ICElib.h) ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
More IPv6 RedHat 6.2 problems compiles but doesn't work
This is with RedHat 6.2. The latest IPv6 fixes allow X to compile, but remote connections no longer work on a machione without IPv6 configured. I've recompiled with XTRANSDEBUG set high (5 I think): % xbiff -display localhost:0 _X11TransOpenCOTSClient(tcp/localhost:0) _X11TransOpen(1,tcp/localhost:0) _X11TransParseAddress(tcp/localhost:0) _X11TransSelectTransport(tcp) _X11TransSocketOpenCOTSClient(tcp,localhost,0) _X11TransSocketSelectFamily(tcp) _X11TransSocketOpen(1,1) _X11TransSocketOpen: socket() failed for tcp _X11TransSocketOpenCOTSClient: Unable to open socket for tcp _X11TransOpen: transport open failed for tcp/localhost:0 Error: Can't open display: localhost:0 % strace shows socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 ENOSYS (Function not implemented) socket(PF_INET6, SOCK_STREAM, 0) = -1 EAFNOSUPPORT (Address family not supported by protocol) For comparison, local connections succeed and report: % xbiff _X11TransOpenCOTSClient(local/:0) _X11TransOpen(1,local/:0) _X11TransParseAddress(local/:0) _X11TransSelectTransport(local) _X11TransSocketOpenCOTSClient(local,harrier,0) _X11TransSocketSelectFamily(local) _X11TransSocketOpen(4,1) _X11TransSocketOpen: returning for local _X11TransConnect(3,local/:0) _X11TransParseAddress(local/:0) _X11TransSocketUNIXConnect(3,harrier,0) ... ... -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: GetImage with 8 bit pseudocolor on a 24/32 bit display
Date: Wed, 09 Jul 2003 16:51:59 -0400 From: Matthew Tippett [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: GetImage with 8 bit pseudocolor on a 24/32 bit display Hello, Trying to work through some problems that I am seeing with X. I have got a TrueColor Display running with 24 bit color (depth 32 bit). Among the visuals available is an 8 bit pseudocolor. A customer has a requirement to use a legacy application that requires the pseudocolor visual. When I run good old 'xv' with the 8 bit pseudocolor, GetImage does some interesting things. The net result is a SEGV in the server. I am using 'xmag' to grab the I'm not having this problem with a Matrox G550 in overlay mode. Can I see your xdpyinfo ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
MGA fixes don't compile
260. Disabled mode writeback to client program from MGA driver (Egbert
Eich).
This doesn't compile on RedHat 6.2 / egcs-2.91.66
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c:3542: warning: preprocessing directive not recognized within macro arg
mga_driver.c: In function `MGASwitchMode':
mga_driver.c:3503: undefined or invalid # directive
mga_driver.c:3505: undefined or invalid # directive
mga_driver.c:3507: undefined or invalid # directive
mga_driver.c:3509: undefined or invalid # directive
mga_driver.c:3523: undefined or invalid # directive
mga_driver.c:3527: undefined or invalid # directive
mga_driver.c: In function `MGAAdjustFrame':
mga_driver.c:3609: warning: implicit declaration of function `HALSetDisplayStart'
make: *** [mga_driver.o] Error 1
This patch expands the macro MGA_HAL() thus allowing the code to compile.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
[EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna
Index: mga_driver.c
===
RCS file: /home/CVS/XFree86/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c,v
retrieving revision 1.234
diff -u -r1.234 mga_driver.c
--- mga_driver.c2003/06/30 16:52:56 1.234
+++ mga_driver.c2003/07/01 07:32:12
@@ -3490,15 +3490,18 @@
char sCmdIn[256];
char sCmdOut[256];
FILE* fdIn;
+#ifdef MATROX_WRITEBACK
FILE* fdOut;
#endif
+#endif
MGAPtr pMga;
ScrnInfoPtr pScrn = xf86Screens[scrnIndex];
pMga = MGAPTR(pScrn);
if (mode-Flags 0x8000) {
#ifdef USEMGAHAL
- MGA_HAL(
+ MGAPtr pMga = MGAPTR(pScrn);
+ if (pMga-HALLoaded HAL_CHIPSETS) {
fdIn = fopen(/tmp/mgaDriverIn, rt);
#ifdef MATROX_WRITEBACK
fdOut = fopen(/tmp/mgaDriverOut, wt);
@@ -3539,7 +3542,7 @@
mode-Flags = 0x7FFF;
return FALSE;
}
- )
+ }
#endif
return FALSE;
} else
Re: MGA fixes don't compile
On Tue, 1 Jul 2003, Egbert Eich wrote: Dr Andrew C Aitchison writes: 260. Disabled mode writeback to client program from MGA driver (Egbert Eich). This doesn't compile on RedHat 6.2 / egcs-2.91.66 Hi Andrew, Yes, thanks! Mattieu already told me. It builds with gcc 3.3 (however issues warnings). I'll commit a little different fix later. I have been thinking to remove the Matrox HAL stuff completely and tell Matrox to ship this stuff in their binary only driver. I had to program around so many things in the HALlib. Furthermore using our driver with this lib is quite rediculous. This lib does allmost all initialization. Only the hw cursor, dri and accel functions are taken from our driver. I'd be very unhappy to lose the HAL; it helps a lot when getting a G550 to work with DVI monitors. Some monitors work without it, but others just don't seem to work unless I use mga_hal_drv.o I believe that the /tmp/mgaDriverIn/Out stuff is only used by the MGA PowerDesktop, and I can live without that, but please don't remove the HAL. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: mkfontscale strikes again
On Tue, 1 Jul 2003, Egbert Eich wrote: Having build options for all kinds of experimental stuff doesn't sound like a realistic solution. Better to have some sandbox separate from the main tree. True. If we had known that this was experimental, a branch of the CVS tree would have made sense. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xterm resize fails
On Wed, 28 May 2003, Dr Andrew C Aitchison wrote: On Wed, 28 May 2003, Thomas Dickey wrote: On Wed, May 28, 2003 at 07:16:08AM -0600, Marc Aurele La France wrote: On Wed, 28 May 2003, Dr Andrew C Aitchison wrote: Patch 3.62 to xc/programs/xterm/screen.c breaks xterm resizing. The call to SET_TTYSIZE no longer happens when TRACE isn't enabled. Fix is to revert to version 3.61 OK. I'll fix it. presumably not by simply rolling back the change... Why not ? Old, working code: -code = SET_TTYSIZE(screen-respond, ts); -TRACE((return %d from SET_TTYSIZE %dx%d\n, code, rows, cols)); New, broken code: +TRACE((return %d from SET_TTYSIZE %dx%d\n, + SET_TTYSIZE(screen-respond, ts), rows, cols)); in the broken version since TRACE(...) is a null macro, cpp removes the call to SET_TTYSIZE. I take some ofthat back. The version without code is definitely wrong. The version with code is working, but is susceptible to optimization. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: IBM port replicator noise?
On Tue, 27 May 2003, Michael B Allen wrote: Additional information DVI resolution higher than 1280x1024 is not supported on A30, A31, and T30 ThinkPads. But this doesn't say explicitly that it's a hardware problem. The noise isn't that bad. It's very very close but not quite. Any ideas? That is pretty close to saying it is a hardware problem. As others have said, hi-res DVI is a suck-it-and-see; basically the DVI spec doesn't go above 1280x1024, so manufacturers have a harder target supporting anything higher. I have a Matrox G550 driving an iiyama flat screen at 1600x1200 with DVI-D, even though the card is only supported upto 1280x1024. The picture is good, but there is some shadowing. The analog-to-digital on good quality flat screens has improved a lot over the years. Can you get an acceptable picture using the analog signal on the DVI port (you may need a DVI-A cable instead of the DVI-D cable you are probably using) ? It is sad, but analog signals may outlast DVI-D :-( -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Colormap Problems in Matrox G450 under FreeBSD 4.8
On Thu, 3 Apr 2003, Peter Gervais wrote: I have an application which requires it uses it own colormap. I'm using the 8+24 mode in the mga driver where the colormap has to be installed in the 8 Pseudo color plane. This application works well unchanged in HP-UX and Solaris 8. When i load the colormap , it affects all other applications on that screen. The xwininfo result indicates the color map has been successfully installed. This is true for most PC hardware in any 8-bit mode* Typically PC graphics hardware only has one palette storing the colormap; many HP and Sun systems have hardware with more than one palette, which solves the problem. In your particular case the 8bit visuals use the palette, but the 24 bit visuals ignore it, so any applications which use 24bit visuals should be unaffected by your unsociable application. Unfortunately the default visual in 8+24 is 8bit, and many applications just use the default, so most applications are affected. You may be able to get around this by starting X with something like: startx -- -cc 4 which will make the 24bit visual the default, although I believe that this stops many 8bit apps. from working; if they are too ignorant to support a 24buit visual they may be unable to find the 8bit pseudocolor visual when it is not the default :-( *The problem also affects any dynamic visual - GrayScale, PseudoColor and DirectColor, and any other visuals implemented the same way; eg TrueColor when gamma-correction is available. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DDC Atoms Xinerama
On 17 Mar 2003, Ben Guthro wrote: However, I'm still left with the dilemma of being unable to inventory all the monitors on the system. I realize that the network transarency schema says that in some instances this does not make sense to do. However, in Windows, Mac OS9, and OS X there is a mechanism to retrieve information on the monitors on the desktop (like each one's EDID), be it virtual or not. Is there no equivalent in X? If you want to inventory all monitors connected to a machine, ddcprobe (ships with Red Hat 8.0) should do that independently of X. I suspect that it doesn't handle multiple monitors very well. If you want to inventory the monitors on a desktop, xprop -root 0x XFree86_DDC_EDID1_RAWDATA should work even across the network. However I haven't tried it on a dual head with two graphics cards. I know that drivers for several dual head cards don't correctly return the EDID info for both displays; do the other OSes you mention get this right ? What does EDID info even mean on a laptop display - my laptop BIOS doesn't return EDID info for the builting screen, but does return the EDID from an external monitor if connected. (II) Loading sub module vbe (II) LoadModule: vbe (II) Loading /usr/X11R6/lib/modules/libvbe.a (II) Module vbe: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.5 (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/X11R6/lib/modules/linux/libint10.a (II) I810(1): initializing int10 (EE) I810(1): Cannot read V_BIOS (II) I810(1): this driver cannot do DDC without VBE This looks like a driver problem - does the DDC work if you driver this card as a single head ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DDC Atoms Xinerama
On 17 Mar 2003, Ben Guthro wrote: This looks like a driver problem - does the DDC work if you driver this card as a single head ? yes. When I remove the ATI Radeon 7500, the i810 correctly gets an EDID. Do you get both EDIDs if you make the i810 the first head in your XF86Config ? --- I've hooked up a dual head system with two ATI cards (r128 and mach64) and confirmed that xprop -display :0.0 -root 8x XFree86_DDC_EDID1_RAWDATA and xprop -display :0.1 -root 8x XFree86_DDC_EDID1_RAWDATA do report the correct EDID info for each monitor. Of course this wont work for Xinerama, since that deliberately hides the display distinction. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Build failure on RedHat 6.2 - setjmp again
Date: Thu, 13 Mar 2003 14:53:10 -0700 (MST) Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Build failure on RedHat 6.2 - setjmp again On Thu, 13 Mar 2003, Dr Andrew C Aitchison wrote: The setjmp changes on 2003/03/12 break build on Red Hat 6.2. It built fine the day before Marc Aurele La France [EMAIL PROTECTED] OK. `cvs update` and try again this now. Thanks Marc, it works again now on Red Hat 6.2 (and still builds on RH8). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DDC Atoms Xinerama
On 13 Mar 2003, Ben Guthro wrote: I am in the process of writing hardware / software monitor color calibration software for linux under Qt. In doing so, determining the monitor hardware that is currently running is quite paramount. The DDC seems to probe the monitors, then store this EDID data in an atom called XFree86_DDC_EDID1_RAWDATA While this method seems to work great in a single monitor environment, a Xinerama environment seems to be different. Since there seems to be a shared Screen between the Xinerama displays - is this EDID data still stored somewhere? Though the full EDID data would be nice, ultimately, I merely need a way off accociating specific screen coordinates to a monitor Vendor / Model / serial number triplet Any insight into this matter would be greatly apprecated Xcms is an existing industry standard color management scheme for X servers. It also uses atoms (such as XDCCC_LINEAR_RGB_MATRICES) to maintain state and make it available to applications/libraries. See man xcmsdb for the way one implementation handles these atoms. I haven't looked at the Xcms code for creating these atoms, so I don't know whether it copes with Xinerama. (I do have a program which can be used with xcmsdb to read XFree86_DDC_EDID1_RAWDATA and create the XDCCC_ atoms, but conventional wisdom is that the color data in many monitor EDIDs is worse than using established defaults - and I've seen figures to prove that). Xinerama didn't exist when I wrote the code for the atoms XFree86_DDC_EDID1_RAWDATA and XFree86_DDC_EDID2_RAWDATA, and I've never got around to looking at what to do. As you say, Xinerama presents a single screen, and thus properties on a single root window, but there are multiple sets of EDID data to present. I've heard talk of ways of refering to the separate heads for use in commands which take a display as argument, but I haven't seen anything working. With Xinerama, since a window may be moved between screens at any time (or appear on more than one at the same time) it isn't really appropriate for a client to ask about the monitor it is displayed on, but I can see that it may be sensible for configuration type applications to have access to both sets of monitor information at the same time. The X log file contains most of the EDID data (and I have a program which can parse most of it) so that might be the easiest way to get what you need. I haven't tried very hard, but I can't remember ever seeing correct EDID data for two monitors into the XFree86_DDC_EDID1_RAWDATA atoms of a dual head setup, and I would definitely not like to rely on it for a dual-head card. Sorry I can't be very positive. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: TV switch
On Mon, 10 Mar 2003, Lawrence Lee (Shanghai) wrote: Hi,all Does xfree86 provide interface about TV switching? I mean that the application can send some requests about TV , then the Xserver receive them and delivery them to DDX driver. The driver can handle the hardware correspondingly. I believe that most (all?) TV input is done via video4linux. xc/programs/Xserver/hw/xfree86/drivers/v4l/README might be the place to start reading. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Fri, 7 Mar 2003, Sven Luther wrote: On Fri, Mar 07, 2003 at 12:31:18PM +, Dr Andrew C Aitchison wrote: On Fri, 7 Mar 2003, Sven Luther wrote: I don't really agree here, modes are for the outgoing resolution, not the input viewport. it would be far simpler to keep this simple acceptation, and add a new keyword for defining the input viewport. Have you looked at the Stretch option on say the NeoMagic driver ? I have a 1024x768 laptop display, and by default (ie unless I use option noStretch) all modes are stretched to fill the screen. Thus the modes (and modelines) describe the viewport size, not the output resolution. Interesting, i suppose the scaling is also done in the driver then, i will have a look at how it works when i get some free time. I wonder how the driver knows what the laptop display size is ? do you specify or does the monitor tell the driver about it with ddc ? The driver gets it from the graphics chip. DDC info on these systems comes from an external mointor if one is connected. DDC for the builtin screen does not exist. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
date.def
xc/config/cf/Imakefile now refers to date.def, and xfree86.cf includes it, but I can't find it in the latest CVS, nor can I find a rule which builds it on the fly. Without this file make World does very little. The Imakefile change appears to be before the 4.2 tag, so we may need to add the file to both branches ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: date.def
On Thu, 27 Feb 2003, Alan Hourihane wrote: On Thu, Feb 27, 2003 at 12:55:21 +, Dr Andrew C Aitchison wrote: xc/config/cf/Imakefile now refers to date.def, and xfree86.cf includes it, but I can't find it in the latest CVS, nor can I find a rule which builds it on the fly. Without this file make World does very little. The Imakefile change appears to be before the 4.2 tag, so we may need to add the file to both branches ? The rule to build it is in xc/Makefile. Thanks. It seems that my xc/Imakefile and xc/Makefile are not being updated by cvs -q update -A -d in the directory above xc, although I am successfully cvsup'ing xc/Imakefile,v I cvsup collections cvs-base/cvs cvs-src/cvs and xc-all/cvs Am I missing something to control the bootstrap ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple video consoles
On Wed, 26 Feb 2003, Yitzhak Bar Geva wrote: What is the status of simultaneous multiple video console operation for full multiuser X on one machine? Someone reported that X works with the multi-head console support in Linux 2.5 kernels. As far as I am concerned, that is the right way to go: get multi-heads working on the console, then run X on top of that. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
On Thu, 20 Feb 2003, Egbert Eich wrote: Guys, please bear with me: why do we need this typedef for xf86jmp_buf at all? This buffer is normally allocated with something like: buf = malloc(sizeof(jmp_buf)); When setjmp.h is included this size is known at compile time. We'd just have to get rid of the defines for xf86jmp_buf in xf86_libc.h (as well as the defines for xf86set/longjmp) and everything should be OK. The the alias isn't needed either. I may not know what I'm talking about. I thought that the problem was that modules are supposed to work across operating system and compiler, so the compile-time size might not be big enough when the module is run on a different system. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Software cursors - was RE: FW: [Xpert]2 mice - 2 pointer ?!?
On Wed, 19 Feb 2003, Rob Taylor wrote: XFree86 still has framework for soft cursors, no? The framework yes, but drivers seem to have problems with DRI and XV and software cursurs, and seem to be trying to disable software cursors. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: FW: [Xpert]2 mice - 2 pointer ?!?
On Tue, 18 Feb 2003, Rob Taylor wrote: Here's a mail that's been sitting in my outbox for a while: its' still relevent so forwarding to Xfree86 Devel. -Original Message- From: Rob Taylor [mailto:[EMAIL PROTECTED]] Sent: 04 February 2003 13:49 To: [EMAIL PROTECTED] Subject: RE: [Xpert]2 mice - 2 pointer ?!? I'm replying to this a bit late on in the day, but i thought i'd give a more concrete example where more than one on-screen pointer is needed. We have a product that can have up to 4 touch screens and has a track-ball controlled pointer. Iften people operate the product in a two-handed manner, and occasionally more than one operator will use the product at a given time. the upshot of this is that ideally there would be a pointer for the trackball that isn't effected by touchscreen presses, and separate invisible pointers for each of the touchscreens. The setup is currently impossible in Xfree86. I'm beginning to understand what you want here. I don't think you really need pointers for the touch-screens; just events when they are pressed. I haven't checked, but I think that one of the standard extensions (perhaps XInputExtension) should be able to do that for you. At some level this isn't really a mouse click; if you want standard apps to behave as if they received a mouse-click, then you want a wrapper app to convert touch-screen presses into synthetic events sent to the standard app (perhaps indirectly via the window manager). Another concrete example is when implementing a collaborative decktop in whcih you want a separate pointer for each of the users remotely viewing that desktop. Are you going to let them type into different windows at the same time ? That really would be two pointers. However I think that should be done by the collaboration software, not by X. I'm not convinced that two pointers are a good idea on a collaborative desktop, forcing the participants to share a pointer helps them to share their focus. Without it they could easily each do their own thing and stop watching what the other one is doing: a good way to reduce the efficiency of the collaboration ? VNC draws a dot cursor to indicate when the pointers at the two ends are out of sync, to make it clear to the remote user that the local user hasn't yet seen what the remote user is pointing at. And don't forget that most current graphics cards only have one hardware cursor. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Release date for 4.3
On Sat, 15 Feb 2003, Florian Lindner wrote: Hello, when do you guess will 4.3 be released? What are your estimates? My guess: When the show-stopping bugs are fixed. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: s3virge bigendian
On Thu, 30 Jan 2003, Meelis Roos wrote: I tried the card in x86 to see if the RAM size is detected right there but I had little success. First the PC didn't like F-COde ROM so the card could not be used as the primary card. Running atimach64 as primary and s3virge as secondary didn't work either - both wanted to decode VGA addresses and some chars appeared on screen but some in the video ram of the other card. Finally it booted up using s3virge dx as primary and this (effectively biosless) s3virge as secondary. But I have big trouble running X - I configured XF 4.2.1 for this card but it tends to hang on DDC, Accel etc. I couldn't squeeze the guessed videoram size out of it so I don't know whether X detects the right videoram size on x86. If you are having problems with DDC you might want to try some of these: Option NoDDC Option NoDDC1 Option NoDDC2 Option NoVBE -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glapi_x86.S glx86asm.py
On Thu, 30 Jan 2003, Alexander Stohr wrote: according to its headline glapi_x86.S was generated by the script glx86asm.py - its just that i cannot find that script in the XFree86 sources. Any hints? From CVS/XFree86/xc/extras/Mesa/bin/Attic/glx86asm.py,v revision 1.2 date: 2000/12/07 16:12:47; author: dawes; state: dead; lines: +0 -0 Remove from the trunk the Mesa files that aren't needed. Latest entry in cvs log of c/extras/Mesa/src/X86/glapi_x86.S revision 1.7 date: 2002/09/09 21:07:33; author: dawes; state: Exp; lines: +1 -1 Mesa 4.0.2 merge (So the script glx86asm.py was removed after glapi_x86.S last changed, which is a good sign). -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: If you were writing a Windows and X clipboard integrationmanager...
On Thu, 30 Jan 2003, Harold L Hunt II wrote: ...how would you do it, in 150 words or less? Seriously, I have been working on this for over a year and I would love to hear some of the ideas that people have because I am completely stumped on how to make such a clipboard manager work properly. I'd be completely lost describing it in 150 words just for X. IIRC there are at least 3 clipboard/cut-buffer mechansims (no I can't remember them all). xprop -root lists 8 CUT_BUFFERX strings (and an atom called _MOTIF_CLIP_FORMAT_ACROBAT_SELECTION) There are about 5 (OK maybe only 3) ways of indicating a clipboard string in a non ascii/latin1 encoding, some of which can't be used by clients in different locales. Throw in MS Windows, and I'd be unhappy unless you can preserve the ability of X to mark in one window and paste in another, using only the mouse. I doubt I'd consider a windowing system without it, at least one based on keyboard+mouse, or even a stylus. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
