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: [PATCH] VidMode fixes [was: bug in XF86VidModeAddModeLine?]
On 13 Mar 2003, Miguel Freitas wrote: May someone with cvs access check and commit this patch? (patch for XFree86 4.3.0) It fixes: - memory leaks at ProcXF86VidModeModModeLine and ProcXF86VidModeValidateModeLine - uninitialized fields of mode structure at ProcXF86VidModeAddModeLine, VidModeCreateMode and VidModeAddModeline (the last one caused a segfault trying to delete the new mode) note: XF86VidModeAddModeLine is _broken_ on current XFree86 releases. Please submit your patch to [EMAIL PROTECTED] so that it goes into the patch queue and doesn't get lost. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
Please don't apply. IT It seems xc/programs/luit/sys.c in XFree86 4.3.0 contains a off-by-one IT bug. A patch (sys.c.patch) to fix this is attached. This is correct. Thanks, I've forwarded it to the patchers. IT - Make luit use openpty to search an unused pty. Without this patch, IT luit aborts after opening ten or so xterms. Could you explain why this happens? allocatePty in sys.c searches through 256 ptys. I strongly dislike the openpty interface, which I feel is badly designed. Indeed, your patch causes luit to open the slave side in the parent, which feel wrong. Your patch also breaks support for systems with SVR4 ptys. This cannot go in. IT - Allow one to setuid luit. This one is incorrect; it is a serious security hole, not only on FreeBSD but on all systems that have saved-ids that don't respect the Posix semantics. Luit will check for Posix saved IDs, and refuse to run if it's setuid on systems that have the (broken) 4.3BSD saved-ids semantics. Your patch merely removes this check. OpenBSD have done the reasonable thing, and abandoned the 4.3BSD saved-ids semantics in favour of the Posix one. FreeBSD haven't, however, and making luit setuid safely under FreeBSD would require using BSD-specific interfaces. This is *not* what you have done. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
IT intro(2) manpage on Solaris, which said: IT | effective user ID and effective group ID prior to an exec of Interesting. Which version of Solaris are you using? I think it must be a documentation bug; it appears to be fixed under 5.8. Check also the execve(2) page. Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Some patches to luit
From: Juliusz Chroboczek [EMAIL PROTECTED] Subject: Re: Some patches to luit Date: 15 Mar 2003 00:01:51 +0100 IT intro(2) manpage on Solaris, which said: IT | effective user ID and effective group ID prior to an exec of Interesting. Which version of Solaris are you using? I think it must be a documentation bug; it appears to be fixed under 5.8. Check also the execve(2) page. I agree that it looks like a documentation bug. I was reading manpages on Solaris 2.6. exec(2) page does not mention anything about saved UID on Solaris 2.6 though intro(2) page refers to exec(2) page. Thanks for pointing it out. Best regards, Tsuyoshi --- ITO Tsuyoshi [EMAIL PROTECTED] --- --- Dept. of Computer Science, University of Tokyo. --- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Origin X and Y of a screen in multi-monitor setting
I am trying to add multi-monitor support to Wacom driver, an input device driver in X kernel. Is there a call to get a screen's origin X and Y from device driver (not from the user space. I know how to do this)? Thanks, Ping ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: DDC Atoms Xinerama
On 13 Mar 2003, Ben Guthro wrote: Xinerama aside, even in a dual head system running without Xinerama, I am having a difficult time retrieving the XFree86_DDC_EDID1_RAWDATA for the second (non-primary) screen xlsatoms |grep EDID yields 69XFree86_DDC_EDID1_RAWDATA 209 XFree86_DDC_EDID1_RAWDATA 489 XFree86_DDC_EDID2_RAWDATA however when running xprop -root |grep EDID on the second screen, it yields no results, and running it on the first screen prints one atom. so...what window are those other two attached to so I can retrieve that information with XGetWindowProperty? Wow, I'd forgotten all about that. In your case xprop -root on the first screen prints the data in atom 209. Atom 69 is a hack; because the EDID data is found before the screen is created, there isn't yet a root window to attach it to. Instead we create a screenless atom (69), then copy it when we create the screen (in xf86Init.c xf86CreateRootWindow() ). XFree86_DDC_EDID2_RAWDATA isn't the data for the second screen. It is used when the monitor returns data in a EDID v2 data structure (256 bytes as opposed to 128). I've never seen a monitor which returns that. There are however monitors which return 128 bytes, but report that they are version 2, since they return it in the structure described in version 2 of the EDID standard (this is really EDID v1.1). We detect this case by the EDID checksum, and create both properties. grepping for EDID in the log file should alert you to that case. Other than that I've never seen an XFree86_DDC_EDID2_RAWDATA property, so would be interested to see your log file. I have more machines than monitors, so haven't looked very hard at the dual head case, and wouldn't be suprised if there are cases where the second head EDID data is wrong or not made 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
