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: xterm resize fails
On Wed, May 28, 2003 at 05:12:45PM +0100, 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. then I'm not sure what part of the source you're looking at, since none of it encloses the SET_TTYSIZE within a TRACE macro. I quoted the lines you cite as Old from the code I last modified in March. Is there a branch you're looking at? -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xterm resize fails
On Wed, May 28, 2003 at 05:20:15PM +0100, Dr Andrew C Aitchison wrote: 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. My guess is that the compiler optimizer is broken, and discarding the assignment. Apparently Marc is guessing the same thing, since he added a (void)code; after the TRACE statement (this is good for gcc, at the expense of increasing the noise level in other compilers). However, if that's the case, a lot more than xterm would be broken, so it would be useful to be able to test this. It's ok to discard int x = 1; if x is never used, but not int x = foo(); -- Thomas E. Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Diamond, Orchid, S3, Supra support/files
I just found out yesterday that the massive archive of docs, drivers, and firmware that was on the the Diamond ftp server [ftp://ftp.diamondmm.com/] is gone. Due to mergers over the years, the archives covered products from these companies and more: Diamond Multimedia Orchid Micronics Supra S3 Obviously, the Diamond Multimedia, Orchid, and S3 files are of the most interest when working with older video cards. The support page for Diamond products [http://www.diamondmm.com/support/diamond/] formerly contained links to files on the ftp server. It now has the following posted: S3 or Diamond Brand Support We no longer support customer service or warranty claims on any of our legacy products sold under the former S3 or Diamond brand. As we no longer manufacture these products, and have not for some time, our customer care and warranty claim call volumes related to these products are extremely low. Because of this, we made the decision to discontinue support for these products. If you are experiencing problems with your Diamond or S3 legacy product please contact an independent repair professional. We appreciate your understanding in this matter and hope that this change does not inconvenience you greatly. The above statement seems totally ludicrous, as how is an independent repair professional (which I think I more than qualify as) supposed to support these products without the files that were available on the ftp site? I put in a call to their technical support staff at (206) 515-1400, and when I selected option '5' for diamond products, it referred me back to the above support url, stating that support files were available on the website. The phone system then hung up, and I called back again selecting the Supra support and 'other' products...same thing. I finally got someone on the line by selecting Supra support and the first and only product the phone system mentioned. I think it was option 4 and 1. Talk about a nightmare. Turns out, they've suddenly had a massive influx of calls from other slightly annoyed customers who still support and use all this obsolete hardware. Personally, I don't see how hardware can be obsolete if it works and does exactly what you need it to. They also seemed to have no clue that older versions of firmware and such are very important when maintaining and supporting these things. The ftp server formerly contained nearly every version that had been released. Now its all gone. Some of these products were only a couple of years old too. I haven't seen any mention of this in the hardware circles yet, but I don't think many people have realized yet what has happened. If anyone else wants to call and ask questions, the phone number above should get you though to someone. I've asked them about returning the ftp site to its former state, as that would seem to be the best solution for everyone right now. Longterm, probably the best thing would be to place the files in the public domain. I would also really like to see programming docs for the S3 and Orchid chips made available and or placed in the public domain, but I have no idea if they even still have them. -Toth ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
DGA2
Hi. I am trying to have dga working without being root under linux 2.4.21-rc2 and Xfree 4.3, setting sgid programs and 660 permission to /dev/mem, but the client cannot open /dev/mem. Even with permissions 777 (:-) ) i get: ls -l /dev/mem crwxrwxrwx1 root giochi 1, 1 2002-12-13 15:51 /dev/mem strace cat /dev/mem ...] open(/dev/mem, O_RDONLY|O_LARGEFILE) = -1 EPERM (Operation not permitted) [... Any idea? Thanx Maurizio Monge ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: extending radeon driver for dual-headed mode
Michel, Thanks for the information. I was able to get rid of the horizontal scan lines on the lcd panel using the XF86Config-4 file below. I have experiemnted with the options in the device section quite a bit and discovered that if I put the Option UseFBDev in both device sections then the external crt gets disabled but if I only put it in the device section for the lcd then it removes the scan lines and the external crt is enabled (although still in clone mode). I also discovered that I need the BusID option in the device section for the external crt but not for the lcd. So basically with this file I have clone mode enabled, no horizontal scan lines on the internal lcd, and a yellow tint on both the lcd and external monitor. I am currently running a 2.4.19 kernel (sid) and am trying to update the drivers/video/radeonfb.c module to v1.23 (latest release) but there seems to be a lot of new dependencies so I may try to just update to a later kernel that has the later radeonfb.c integrated. Ultimately my goal is to get true independent dual-heads enabled. -dean andreakis Section Files RgbPath /usr/X11R6/lib/X11/rgb FontPath unix/:7100 EndSection Section Module Load dbe Load v4l Load extmod Load fbdevhw Load glx Load record Load freetype Load type1 Load dri EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout us EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol IMPS/2 Option Device /dev/input/mice Option ZAxisMapping 4 5 Option Emulate3Buttons no EndSection Section InputDevice Identifier DevInputMice Driver mouse Option Protocol IMPS/2 Option Device /dev/input/mice Option ZAxisMapping 4 5 Option Emulate3Buttons no EndSection Section Monitor Identifier lcd VendorName Generic ModelName Flat Panel 1400x1050 Option dpms EndSection Section Monitor Identifier external-21in VendorName Monitor Vendor ModelNameDell 1800FP (Analog) Option dpms EndSection Section Device Identifier radeon-lcd VendorName ATI BoardName ATI Radeon Driver radeon Screen 0 Option UseFBDev EndSection Section Device Identifier radeon-external VendorName ATI BoardName ATI Radeon Driver radeon Screen 1 BusID PCI:0:16:0 EndSection Section Screen Identifier lcd-screen Device radeon-lcd Monitor lcd DefaultDepth 24 Subsection Display Depth 8 Modes 1024x768 800x600 640x480 EndSubsection Subsection Display Depth 15 Modes 1024x768 800x600 640x480 EndSubsection Subsection Display Depth 16 Modes 1024x768 800x600 640x480 EndSubsection Subsection Display Depth 24 Modes 1024x768 800x600 640x480 EndSubsection EndSection Section Screen Identifier external-21in-screen Device radeon-external Monitor external-21in DefaultDepth 24 SubSection Display Depth24 Modes1024x768 800x600 640x480 EndSubsection EndSection Section ServerLayout Identifier default InputDevice Keyboard0 CoreKeyboard InputDevice Mouse0 CorePointer InputDevice DevInputMice SendCoreEvents Screen lcd-screen Screen external-21in-screen LeftOf lcd-screen EndSection Section DRI Group0 Mode 0666 EndSection -Original Message- From: Michel Dänzer [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2003 5:26 PM To: [EMAIL PROTECTED] Subject: RE: extending radeon driver for dual-headed mode On Wed, 2003-05-21 at 17:04, Andreakis, Dean (MED) wrote: 1. DRI on my x86/RH9 is now disabled where it was enbled before the changes.I will post my XF86Config and log file to the dri users list. See http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 2. I tried the same cfg. on my iBook/Debian(sid) machine and it enabled clone mode and the colors all have a yellow tint. The lcd also has horizontal lines running through it. This one is a bit tricky. You basically need a recent radeonfb and Option UseFBDev for the internal panel to work correctly, but then the behaviour of the second head is undefined. You can find some success stories in the archives of the debian-powerpc mailing list though. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Having trouble getting CVS to compile
On 27 May 2003, Scott White wrote: Could anyone point me at some instructions to help me compile the XFree86 cvs, I'm having trouble. I want to get access to the via driver recently added to the CVS so I can run X not in vesa mode on my Via Mini-itx based hush PC running Redhat 9. The easiest way to get the via driver without damaging your Red Hat supplied X installation, is to wait a few days or so, and I'll be integrating it into XFree86 4.3.0 in rawhide. Rawhide XFree86 should be a fairly clean upgrade from the stock RHL 9 XFree86. It'll likely be in 4.3.0-14 or 4.3.0-15. You can find me in IRC on freenode #xfree86 if you'd also like to ping me on wether I've added it yet or not. HTH -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
