Re: [PATCH] Radeon Xv gamma support
On Fri, 19 Dec 2003, Alex Deucher wrote: This patch adds two new XV attributes: XV_COLORSPACE and XV_GAMMA. XV_GAMMA lets you adjust the gamma of the overlay to 8 presets: 0 - gamma 1.0, default 1 - 0.85 ... ... 7 - 2.5 Please let me know if you have any suggestions or find any bugs with this code. The patch is against DRI cvs, but should apply pretty easily to xfree86 or gatos as well. Can I suggest that the API exposes the options in some device neutral manner - ideally a float - which the driver converts to the nearest available preset. Either nVidia or the next generation Radeon is bound to use 16 presets, or calculate the table for an given gamma ? Unless the preset list of gamma values follows some standard (sorry if it does) applications should be able to ask for the value they want, and have something sensible happen ? Andew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] Radeon Xv gamma support
Andrew C Aitchison wrote: On Fri, 19 Dec 2003, Alex Deucher wrote: This patch adds two new XV attributes: XV_COLORSPACE and XV_GAMMA. XV_GAMMA lets you adjust the gamma of the overlay to 8 presets: 0 - gamma 1.0, default 1 - 0.85 ... ... 7 - 2.5 Please let me know if you have any suggestions or find any bugs with this code. The patch is against DRI cvs, but should apply pretty easily to xfree86 or gatos as well. Can I suggest that the API exposes the options in some device neutral manner - ideally a float - which the driver converts to the nearest available preset. Either nVidia or the next generation Radeon is bound to use 16 presets, or calculate the table for an given gamma ? Unless the preset list of gamma values follows some standard (sorry if it does) applications should be able to ask for the value they want, and have something sensible happen ? I think floats isn't possible via XV properties. But I have another suggestion (based on the assumption that you can handle separate gamma values for r, g, b): Make three properties (such as for example XV_GAMMA_RED etc) and allow a range from 1000 to 1, which is the desired value * 1000. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] documentation fix addition for config/cf/README
David Dawes wrote: It still fails in the same way. Tabs have been converted to spaces, either by your mailer or because you cut'n'pasted it. Try sending it as an attachment. done wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org--- ../../../xc-old/config/cf/README 2003-04-25 06:00:03.0 -0500 +++ README 2003-12-10 22:47:32.0 -0600 @@ -25,7 +25,6 @@ CURDIR current directory relative to top of sources CcCmd command to run C compiler CompressCmd command to run compress program - GzipCmd command to run gzip program ConstructMFLAGS System V option to set MFLAGS make variable CpCmd command to copy one file to another CplusplusCmd command to run C++ compiler @@ -50,6 +49,7 @@ FortranCmd command to run Fortran compiler FortranDebugFlags flags for Fortran debug info FortranFlags Fortran compiler flags + GzipCmd command to run gzip program HasBSD44Sockets boolean for system has BSD4.4 sockets HasBsdMake use the 4.4BSD variant of the make program? HasBsearch boolean for libc has bsearch() @@ -218,6 +218,8 @@ DefaultUserPath default user xdm PATH environment variable DependCmd command to run makedepend DependDir build directory containing makedepend program + DriverManDir directory in which to install driver man pages + DriverManSuffix man suffix for driver pages ExtensionDefines -D's for universal extensions ExtensionOSDefines -D's for additional extensions FontCompilerFlags flags for bdftosnf @@ -246,6 +248,7 @@ ManSourcePath common prefix of man page directories ManSuffix man suffix for programs MiscManSuffix man suffix for miscellaneous pages + MiscManDir directory in which to install misc man pages NeedDefaultDepLibs boolean for enabling default DEPLIBS NlsDir directory in which to install nls files NormalLibFS build libFS.a
Re: XFree86 master cvsup server refuses authentication
Mike A. Harris wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. David Dawes posted a message about this to [EMAIL PROTECTED] on Nov 2nd. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
VIA Driver problems
Hi folks, I've just compiled 4.3.99.902 on my PC runing NetBSD-current. As with previous versions of XFree86 I found that the VIA driver still crashes due to a problem withthe VIAFindModeUseBIOSTable() function in via_bios.c. This function uses a field that is not initialized: /* Default settings have not been loaded, they must be obtained from the BIOS */ pBIOSInfo-pUTUSERSETTING-DefaultSetting = FALSE; When I try to start X the value of pBIOSInfo-pUTUSERSETTING is NULL. This causes a segmentation fault. I can't find any initialization at all of this field in the code, so I tried to allocate memory to the field: *** via_driver.c.org Sat Dec 20 14:43:24 2003--- via_driver.c Sat Dec 20 14:16:49 2003** 449,454 --- 449,456 xnfcalloc(sizeof(VIABIOSInfoRec), 1); ((VIARec *)(pScrn-driverPrivate))-pBIOSInfo-pModeTable = xnfcalloc(sizeof(VIAModeTableRec), 1);+ ((VIARec *)(pScrn-driverPrivate))-pBIOSInfo-pUTUSERSETTING =+ xnfcalloc(sizeof(UTUSERSETTING), 1); /* initial value in VIARec */ ((VIARec *)(pScrn-driverPrivate))-SavedReg.mode = 0xFF; With this, the Xserver starts and it seems to work. OK, I still have some problems when exiting X. I don't know if this is the right way to solve this problem, but it is easy to understand that the server crashes without some form of initialization of this field. - Jan
Re: 4.3.902 bug report
Warren Turkal wrote (in a message from Saturday 20) The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It appears that stdint.h needs to be included somewhere (most likely Xos.h), but it is not. It appears that uint32_t was changed from u_int32_t in some SCO fixes. I have included output from trying to compile below. I think you're right here. Since we can't assume that every platform on which XFree86 is built has C99 types and that there's no previous art of using uint32_t instead of the older u_int32_t in the XFree86 tree, the SCO diff should be reverted and changed to something that will define u_int32_t on SCO if needed. For a later XFree86 release we shoud consider switching to C99 types everywhere and providing definitions for systems that don't have stdint.h nor inttypes.h. But this is not something to do so close to a release. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] Radeon Xv gamma support
yeah, I had thought about that too. I guess we need to decide what's a good way to advertise gamma. I just did it that way since I had 8 presets, but like you said there could be more down the road. The hardware is capable of independently adjusting 18 points (6 on r100 hw) along the gamma curve. I just worked out some common gamma values since I don't know of a good way to expose the curve. We can't use float values for attributes (perhaps we could add float support to the device independant Xv code), but we can use ints like 85 for 0.85 or 110 for 1.1. the question is, what should the limit be? 300? 400? should we multiply by 1000 instead of 100? having a basic XV_GAMMA attribute is probably easier for users than having XV_GAMMA_RED, etc. especially since not all hardware does gamma the same way. Thoughts? Alex --- Thomas Winischhofer [EMAIL PROTECTED] wrote: Andrew C Aitchison wrote: On Fri, 19 Dec 2003, Alex Deucher wrote: This patch adds two new XV attributes: XV_COLORSPACE and XV_GAMMA. XV_GAMMA lets you adjust the gamma of the overlay to 8 presets: 0 - gamma 1.0, default 1 - 0.85 ... ... 7 - 2.5 Please let me know if you have any suggestions or find any bugs with this code. The patch is against DRI cvs, but should apply pretty easily to xfree86 or gatos as well. Can I suggest that the API exposes the options in some device neutral manner - ideally a float - which the driver converts to the nearest available preset. Either nVidia or the next generation Radeon is bound to use 16 presets, or calculate the table for an given gamma ? Unless the preset list of gamma values follows some standard (sorry if it does) applications should be able to ask for the value they want, and have something sensible happen ? I think floats isn't possible via XV properties. But I have another suggestion (based on the assumption that you can handle separate gamma values for r, g, b): Make three properties (such as for example XV_GAMMA_RED etc) and allow a range from 1000 to 1, which is the desired value * 1000. Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
I wrote (in a message from Saturday 20) Warren Turkal wrote (in a message from Saturday 20) The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It appears that stdint.h needs to be included somewhere (most likely Xos.h), but it is not. It appears that uint32_t was changed from u_int32_t in some SCO fixes. I have included output from trying to compile below. I think you're right here. Since we can't assume that every platform on which XFree86 is built has C99 types and that there's no previous art of using uint32_t instead of the older u_int32_t in the XFree86 tree, the SCO diff should be reverted and changed to something that will define u_int32_t on SCO if needed. On a 2nd thought, I guess using CARD32 here is fine. I have somewhere the idea that CARD32 and such types were reserved to describe the on-the-wire X protocol, but there are alreadt many (ab)uses of it in some drivers. semantically CARD32 is the same as uint32_t and u_int32_t anyways. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] documentation fix addition for config/cf/README
On Sat, Dec 20, 2003 at 07:16:43AM -0600, Warren Turkal wrote: David Dawes wrote: It still fails in the same way. Tabs have been converted to spaces, either by your mailer or because you cut'n'pasted it. Try sending it as an attachment. done That one worked, and I've just committed it. Thanks. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
On Sat, Dec 20, 2003 at 07:14:36PM +0100, Matthieu Herrb wrote:
I wrote (in a message from Saturday 20)
Warren Turkal wrote (in a message from Saturday 20)
The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It
appears that stdint.h needs to be included somewhere (most likely Xos.h),
but it is not. It appears that uint32_t was changed from u_int32_t in some
SCO fixes. I have included output from trying to compile below.
I think you're right here. Since we can't assume that every platform
on which XFree86 is built has C99 types and that there's no previous
art of using uint32_t instead of the older u_int32_t in the XFree86
tree, the SCO diff should be reverted and changed to something that
will define u_int32_t on SCO if needed.
On a 2nd thought, I guess using CARD32 here is fine. I have somewhere
the idea that CARD32 and such types were reserved to describe the
on-the-wire X protocol, but there are alreadt many (ab)uses of it in
some drivers.
We use them in lots of places that require known size data types. If
the C99 types had been globally available say 10 years earlier, this
likely wouldn't have been the case. As it is now, we either need to
find a mechanism for providing the C99 types on platforms that don't
have them, or continue using the CARD{8,16,32} and INT{8,16,32} types,
and also provide CARD64 and INT64 on more platforms than we currently
do.
Definitely something to follow up soon after the 4.4.0 release.
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] Radeon Xv gamma support
On Sat, 20 Dec 2003, Alex Deucher wrote: yeah, I had thought about that too. I guess we need to decide what's a good way to advertise gamma. I just did it that way since I had 8 presets, but like you said there could be more down the road. The hardware is capable of independently adjusting 18 points (6 on r100 hw) along the gamma curve. I just worked out some common gamma values since I don't know of a good way to expose the curve. We can't use float values for attributes (perhaps we could add float support to the device independant Xv code), but we can use ints like 85 for 0.85 or 110 for 1.1. the question is, what should the limit be? 300? 400? should we multiply by 1000 instead of 100? The EDID (Extended Display indentification Data) standard used by Monitor DDC, encodes gamma values in the range [1.0,3.56) usual one byte with: encodedValue = (gamma*100)-100 Since we have a CARD32 we could use gamma = 1.0 + (encodedValue*(100.0/0x100)) having a basic XV_GAMMA attribute is probably easier for users than having XV_GAMMA_RED, etc. especially since not all hardware does gamma the same way. DDC and xgamma both allow either a single gamma, or one for each channel. If we don't allow separate channels now, we will only need to add the option later. Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VIA Driver problems
On 2003.12.20 15:49, Jan Thorsson wrote: Hi folks, I've just compiled 4.3.99.902 on my PC runing NetBSD-current. As with previous versions of XFree86 I found that the VIA driver still crashes due to a problem with the VIAFindModeUseBIOSTable() function in via_bios.c. This function uses a field that is not initialized: /* Default settings have not been loaded, they must be obtained from the BIOS */ pBIOSInfo-pUTUSERSETTING-DefaultSetting = FALSE; When I try to start X the value of pBIOSInfo-pUTUSERSETTING is NULL. This causes a segmentation fault. I can't find any initialization at all of this field in the code, so I tried to allocate memory to the field: *** via_driver.c.orgSat Dec 20 14:43:24 2003 --- via_driver.cSat Dec 20 14:16:49 2003 *** *** 449,454 --- 449,456 xnfcalloc(sizeof(VIABIOSInfoRec), 1); ((VIARec *)(pScrn-driverPrivate))-pBIOSInfo-pModeTable = xnfcalloc(sizeof(VIAModeTableRec), 1); + ((VIARec *)(pScrn-driverPrivate))-pBIOSInfo-pUTUSERSETTING = + xnfcalloc(sizeof(UTUSERSETTING), 1); /* initial value in VIARec */ ((VIARec *)(pScrn-driverPrivate))-SavedReg.mode = 0xFF; With this, the Xserver starts and it seems to work. OK, I still have some problems when exiting X. I don't know if this is the right way to solve this problem, but it is easy to understand that the server crashes without some form of initialization of this field. - Jan Was reported before (see following bugreport content). Now Opened as http://bugs.xfree86.org/show_bug.cgi?id=1006 Luc Verhaegen. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
On Sat, 20 Dec 2003, Warren Turkal wrote:
David Dawes wrote:
We use them in lots of places that require known size data types. If
the C99 types had been globally available say 10 years earlier, this
likely wouldn't have been the case. As it is now, we either need to
find a mechanism for providing the C99 types on platforms that don't
have them, or continue using the CARD{8,16,32} and INT{8,16,32} types,
and also provide CARD64 and INT64 on more platforms than we currently
do.
If you can make stdint.h be included, it would fix this I think. There
appears to be some magic that tries to include that file under certain
circumstances. That is the header that defines the standard int types for
C99.
You're not listening. stdint.h and inttypes.h are _not_ available on
all platforms XFree86 builds on.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 master cvsup server refuses authentication
On Sat, 20 Dec 2003, David Dawes wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. There was no public announcement because this was never a publicly available service, as you well know since it required an unpublished password for access. Those affected by the change (the committers) were notified of the change. Yes, I am well aware it required a password. I was affected by the change, and I was not a committer. You are the one who gave out the password in the first place. Everyone else has equal access to our public anoncvs site which is well documented on our web site. That is perfectly fine. I am not complaining at all in any way about level of access. I am more than perfectly happy to use the public anonymous access. I find it just a tad duplicitous that you complain about the loss of the privileged access that you yourself campaigned to abolish. Wrong. I am not in any way complaining about loss of priveledged access. In fact, I don't care at all about that, and I have absolutely no interest whatsoever in _ever_ having priveledged access to anything from XFree86.org to be quite honest. So don't twist words thanks. What I am complaining about, is that people, including myself, whom did have authorized access to a particular service, and have been using it for over two years, did not receive proper notification that that service would be terminating. Yes, some of the Nazgul did, but they weren't the only ones with authorized access to those services. All I am asking, is that prior to disabling something people use every day, it is polite to at least notify them of this. The only reason I (or anyone else for that matter) would use the master repositories, is that they are a bit faster, and always more up to date than a mirror. I would have gladly started using the public mirror a year ago however, had I been asked to, or had I known that the master repository access was going bye-bye. It was an oversight that this service wasn't terminated at the same time as the other old member-only services when this list as opened up, and for that oversight I apologise. That's fine, apology accepted. But please don't try to make it look like I'm upset about losing special access, as that is not at all the case. I'm upset because I've done many cvs rdiff operations in which I did not get the results I expected and didn't have the time to figure out why, so I moved on to other things. If there is anything else that I have any priveledged access to with the master XFree86 password, please immediately revoke my access to it, and notify me of the change if you'd be so kind. I would much prefer that over surprises like this. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 master cvsup server refuses authentication
On Sat, Dec 20, 2003 at 07:38:03PM -0500, Mike A. Harris wrote: If there is anything else that I have any priveledged access to with the master XFree86 password, please immediately revoke my access to it, and notify me of the change if you'd be so kind. Notification was implied at the time formal membership was abandoned. I can't imagine why you would have assumed otherwise. Any further use by anybody of the old devel password is unauthorised as of now. To the best of my knowledge no such services remain, but if there is something else that I have missed, further use of it is explicitly not authorised. There will be no further announcements with respect to such services. I hope that is clear enough for you. And again, my apologies to everyone else for the fact that some still had access not generally available to the public. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 master cvsup server refuses authentication
Mike A. Harris wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. David Dawes posted a message about this to [EMAIL PROTECTED] on Nov 2nd. I've *never* been subscribed to [EMAIL PROTECTED], which was a closed and private list always, and not ever open to public subscription. That list, as far as I know, is strictly limited to people who have CVS write permission. So obviously, the message never reached the full list of people who had access to the master cvs/cvsup server. Sorry, I didn't know how deeply you're involved (or not involved, for that matter) in development. I just meant to give you a hint, and if David didn't post this on devel or xfree, I'd have assumed he had his reasons (which is why I didn't forward his message to you/this list - and no, I'm not the one making up secrets here). Hm, I really should shut up when it comes to political issues here... (take this as a note to self, so to speak) Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net http://www.winischhofer.net/ twini AT xfree86 DOT org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 master cvsup server refuses authentication
On Sun, Dec 21, 2003 at 04:09:35AM +0100, Thomas Winischhofer wrote: Mike A. Harris wrote: It worked up until November first according to my cvsup cronjob logs, at which point it just stopped. However, now that you mention it, I don't remember ever seeing any public announcement that the cvsup server would be decommissioned earlier this year, nor any time prior to it becoming unavailable in November. David Dawes posted a message about this to [EMAIL PROTECTED] on Nov 2nd. I've *never* been subscribed to [EMAIL PROTECTED], which was a closed and private list always, and not ever open to public subscription. That list, as far as I know, is strictly limited to people who have CVS write permission. So obviously, the message never reached the full list of people who had access to the master cvs/cvsup server. Sorry, I didn't know how deeply you're involved (or not involved, for that matter) in development. I just meant to give you a hint, and if David didn't post this on devel or xfree, I'd have assumed he had his reasons (which is why I didn't forward his message to you/this list - and no, I'm not the one making up secrets here). Hm, I really should shut up when it comes to political issues here... (take this as a note to self, so to speak) There's no big issue here. Committers have access to the master repository (by definition). Everyone else has read-only access to the mirror of the master that is on our public access server. The details of the public access information are on our web server, and that information is kept up to date. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
