[ANNOUNCE] xorg-server 1.7.6
The sixth stable update for the X server 1.7 is now available. As promised, no big changes anymore since the last RC. One build fix caused by a botched merge and two minor fixes for XQuartz. Jeremy Huddleston (2): XQuartz: Use an empty xkb keymap by default Revert "XQuartz: Explicitly pass a bellProc to make XBell() work again." Peter Hutterer (2): configure: restore SHA1_LIB for XSERVER_SYS_LIBS xserver 1.7.6 git tag: xorg-server-1.7.6 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.7.6.tar.bz2 MD5: 178225f499ec10fa9d312d1c339e6a39 xorg-server-1.7.6.tar.bz2 SHA1: 77a8c3dec86960e1be818df3a75d69b5fad6a3c0 xorg-server-1.7.6.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.7.6.tar.gz MD5: ba0360b4ec1f6e541b264e45906bf5f2 xorg-server-1.7.6.tar.gz SHA1: 1417353f305c34f51fe9a906358a82a59661fd1a xorg-server-1.7.6.tar.gz pgpwlRASdmRBt.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Please help with Xorg
On 16 March 2010 13:48, Roland Scheidegger wrote: > On 16.03.2010 02:50, John Tapsell wrote: >> On 15 March 2010 20:03, Simone Azzalin wrote: >>> >Just to eliminate the stupid questions first.. > Is your screen TFT, and if so, what is its native resolution? :) >>> Resolutions always worked fine with many distros, but in the last times it >>> happens with recents distros for example.. >>> The first resolution proposed is 1200 x 920 (if I remember well because I'm >>> on another pc right now ) >> >> Okay so that's a ratio of 1200/920 = 5/4 = 1.25 >> But you're trying to use a resolution of 1024/768 = 4/3 = 1.33 >> >> So it's no wonder you're getting black bars. The picture just doesn't >> fit on the screen. >> >> If it used to 'work', probably you just set some setting on the >> monitor to stretch the screen to fit, instead of adding black bars. >> >> So, either run in 1200/920 or play about with the monitor settings to >> find a way to make it stretch instead of adding black bars. >> >> I think this has nothing to do with linux or xorg. > > Well if that's a notebook lvds panel, those don't come with scalers, Ah good point - reviewing the first email, he does indeed say that this is a laptop. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Yeelong and SiliconMotion driver: asking for developers
On Tue, Mar 16, 2010 at 6:36 PM, Daniel Stone wrote: > Hi, > > On Tue, Mar 16, 2010 at 02:49:13PM -0400, Brett Smith wrote: >> When we started looking at software for the SiliconMotion hardware (as >> part of evaluating how free software-friendly a particular machine was), >> we found a modified driver from the SiliconMotion company that seemed to >> have some useful changes. The company was distributing it under GPLv2 >> only. >> >> Some of the developers who were packaging software for the machine >> pointed out that this license was unfortunate for them, because they >> were interested in getting GRUB running on the box as well, and of >> course, GPLv2-only is not a compatible license for a GPLv3-covered >> project like GRUB. With that issue in front of him, RMS asked >> SiliconMotion to allow the code to be used under the terms of GPLv3, one >> way or another, which they agreed to. >> >> Please don't read any malice into that request, because I assure you >> there was none. The FSF has consistently advocated that developers >> should use licenses that are consistent with the larger projects they >> interact with (as long as those licenses are free and GPL-compatible), >> and that advice definitely applies to Xorg drivers. If we made a >> mistake here, it was a failure to connect the dots. As weird as it >> might sound, I don't think it was clear at the time that we were talking >> about the licensing of an entire Xorg driver. If we had known that, we >> would've asked SiliconMotion to switch to the X11 license, if possible, >> to stay consistent with Xorg generally. >> >> And I'm happy to talk to SiliconMotion about that now. I don't know if >> you have a usual way of handling licensing requests like this, but if >> you want me to keep anybody or any lists in the loop on that thread, >> that's no problem either; just let me know. And either way, if you have >> any other questions or concerns about this, please don't hesitate to ask >> me. > > Fair enough -- sorry if my reply was a bit harsh. It'd be great if you > guys were willing to work with SMI to get it relicensed to MIT/X11, as > for better or worse, we only accept MIT/X11 or non-four-clause BSD. We > do host the development of some GPL drivers (xf86-input-synaptics, > xf86-video-avivo), but we don't distribute these as a part of X.Org at > all. Even so, these are GPLv2 rather than GPLv3, which would be a lot > more problematic. FWIW, SMI has been involved in the siliconmotion xorg driver before (they contributed a fair amount of the original code), although most of the recent work has been done by contributors. Alex ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Yeelong and SiliconMotion driver: asking for developers
Hi, On Tue, Mar 16, 2010 at 02:49:13PM -0400, Brett Smith wrote: > When we started looking at software for the SiliconMotion hardware (as > part of evaluating how free software-friendly a particular machine was), > we found a modified driver from the SiliconMotion company that seemed to > have some useful changes. The company was distributing it under GPLv2 > only. > > Some of the developers who were packaging software for the machine > pointed out that this license was unfortunate for them, because they > were interested in getting GRUB running on the box as well, and of > course, GPLv2-only is not a compatible license for a GPLv3-covered > project like GRUB. With that issue in front of him, RMS asked > SiliconMotion to allow the code to be used under the terms of GPLv3, one > way or another, which they agreed to. > > Please don't read any malice into that request, because I assure you > there was none. The FSF has consistently advocated that developers > should use licenses that are consistent with the larger projects they > interact with (as long as those licenses are free and GPL-compatible), > and that advice definitely applies to Xorg drivers. If we made a > mistake here, it was a failure to connect the dots. As weird as it > might sound, I don't think it was clear at the time that we were talking > about the licensing of an entire Xorg driver. If we had known that, we > would've asked SiliconMotion to switch to the X11 license, if possible, > to stay consistent with Xorg generally. > > And I'm happy to talk to SiliconMotion about that now. I don't know if > you have a usual way of handling licensing requests like this, but if > you want me to keep anybody or any lists in the loop on that thread, > that's no problem either; just let me know. And either way, if you have > any other questions or concerns about this, please don't hesitate to ask > me. Fair enough -- sorry if my reply was a bit harsh. It'd be great if you guys were willing to work with SMI to get it relicensed to MIT/X11, as for better or worse, we only accept MIT/X11 or non-four-clause BSD. We do host the development of some GPL drivers (xf86-input-synaptics, xf86-video-avivo), but we don't distribute these as a part of X.Org at all. Even so, these are GPLv2 rather than GPLv3, which would be a lot more problematic. For legal issues, the Foundation Board (bo...@foundation.x.org) handles all of that, and just ask the list or myself about technical stuff (SMI driver, code hosting, etc). Cheers, Daniel pgpWktpU1J30o.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Yeelong and SiliconMotion driver: asking for developers
Hi, On Tue, Mar 16, 2010 at 05:19:40PM -0400, Daniel Clark wrote: > 2010/3/16 Bridgman, John : > > Ahh, that makes sense -- so the relicensing from X11 to GPLv2 already > > happened, and the proposed relicensing was going to be from GPLv2 to v3. > > Asking if the code can be licensed back to X11 (allowing use in the X.org > > project) certainly sounds like a good next step. > > I'm glad we got that misunderstanding out of the way. > > If anyone is psyched to work on this, but doesn't have hardware, > Brett/FSF and/or I/Freedom Included and/or Octavio/Poder Digital can > work with Xorg donations people to get a Lemote Yeeloong to the Xorg > project. > > It looks like this chipset is also in some other stuff, like some > older Thinkpads: > http://www.thinkwiki.org/wiki/SMI_LynxEM (checked and you can get some > of them for $50-$100 on ebay). As with all other drivers, if someone seriously wants to maintain it but doesn't have the hardware, then the Foundation has a hardware budget set aside for exactly this. Cheers, Daniel pgpdLrxvmEsQy.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Yeelong and SiliconMotion driver: asking for developers
2010/3/16 Bridgman, John : > Ahh, that makes sense -- so the relicensing from X11 to GPLv2 already > happened, and the proposed relicensing was going to be from GPLv2 to v3. > Asking if the code can be licensed back to X11 (allowing use in the X.org > project) certainly sounds like a good next step. I'm glad we got that misunderstanding out of the way. If anyone is psyched to work on this, but doesn't have hardware, Brett/FSF and/or I/Freedom Included and/or Octavio/Poder Digital can work with Xorg donations people to get a Lemote Yeeloong to the Xorg project. It looks like this chipset is also in some other stuff, like some older Thinkpads: http://www.thinkwiki.org/wiki/SMI_LynxEM (checked and you can get some of them for $50-$100 on ebay). Happy Hacking, -- Daniel JB Clark | http://pobox.com/~dclark | Activist; Owner \|/ FREEDOM -+-> INCLUDED ~ http://freedomincluded.com /|\ Free Software respecting hardware ~ Lemote Yeeloong reseller ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Yeelong and SiliconMotion driver: asking for developers
Ahh, that makes sense -- so the relicensing from X11 to GPLv2 already happened, and the proposed relicensing was going to be from GPLv2 to v3. Asking if the code can be licensed back to X11 (allowing use in the X.org project) certainly sounds like a good next step. I don't know if there is a formal process for determining if a proposed licensing change is "appropriate" but I imagine that would be a board decision after the request was kicked around on the xorg mailing list as it is now... so everything is probably happening as it should. I'm only guessing so if you get a different answer from someone else go with that ;) -Original Message- From: Brett Smith [mailto:br...@fsf.org] Sent: Tuesday, March 16, 2010 2:49 PM To: Bridgman, John Cc: 'Daniel Clark'; Daniel Stone; Owain Ainsworth; Octavio Rossell; xorg@lists.freedesktop.org; Vladimir 'φ-coder/phcoder' Serbinenko; Bernie Innocenti Subject: RE: Yeelong and SiliconMotion driver: asking for developers Hi everyone, I'm sorry for the confusion that's sprung up around this issue. I hope I can get everything clarified -- I think we're all really on the same page here about what would be ideal. On Tue, 2010-03-16 at 10:16 -0700, Bridgman, John wrote: > Is there a reason that graphics code can not be included in the GRUB2 project > with its current license ? > > My recollection was that the X11 license was considered "GPL compatible" in > the sense that it *could* be relicensed if necessary. Graphics driver code is > included in the Linux kernel without relicensing, ie it retains its current > X11 license even though it lives in an otherwise GPLv2-licensed tree. > > Is there something about GPLv3 which prevents the same approach from being > used, or are we just talking about a GRUB2 project rule which disallows > "compatible" licenses and requires actual GPLv3 licensing ? None of those is the case. Your understanding about compatibility is correct, all the same rules apply to GPLv3, and there's no GRUB project policy that would prevent them from including X11-licensed code. When we started looking at software for the SiliconMotion hardware (as part of evaluating how free software-friendly a particular machine was), we found a modified driver from the SiliconMotion company that seemed to have some useful changes. The company was distributing it under GPLv2 only. Some of the developers who were packaging software for the machine pointed out that this license was unfortunate for them, because they were interested in getting GRUB running on the box as well, and of course, GPLv2-only is not a compatible license for a GPLv3-covered project like GRUB. With that issue in front of him, RMS asked SiliconMotion to allow the code to be used under the terms of GPLv3, one way or another, which they agreed to. Please don't read any malice into that request, because I assure you there was none. The FSF has consistently advocated that developers should use licenses that are consistent with the larger projects they interact with (as long as those licenses are free and GPL-compatible), and that advice definitely applies to Xorg drivers. If we made a mistake here, it was a failure to connect the dots. As weird as it might sound, I don't think it was clear at the time that we were talking about the licensing of an entire Xorg driver. If we had known that, we would've asked SiliconMotion to switch to the X11 license, if possible, to stay consistent with Xorg generally. And I'm happy to talk to SiliconMotion about that now. I don't know if you have a usual way of handling licensing requests like this, but if you want me to keep anybody or any lists in the loop on that thread, that's no problem either; just let me know. And either way, if you have any other questions or concerns about this, please don't hesitate to ask me. Thanks, -- Brett Smith Licensing Compliance Engineer, Free Software Foundation Join us in Cambridge for LibrePlanet, March 19th-21st! http://groups.fsf.org/wiki/LibrePlanet2010 ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Yeelong and SiliconMotion driver: asking for developers
Is there a reason that graphics code can not be included in the GRUB2 project with its current license ? My recollection was that the X11 license was considered "GPL compatible" in the sense that it *could* be relicensed if necessary. Graphics driver code is included in the Linux kernel without relicensing, ie it retains its current X11 license even though it lives in an otherwise GPLv2-licensed tree. Is there something about GPLv3 which prevents the same approach from being used, or are we just talking about a GRUB2 project rule which disallows "compatible" licenses and requires actual GPLv3 licensing ? -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Daniel Clark Sent: Tuesday, March 16, 2010 11:25 AM To: Daniel Stone; Owain Ainsworth; Octavio Rossell; xorg@lists.freedesktop.org Cc: Vladimir 'φ-coder/phcoder' Serbinenko; Bernie Innocenti; Brett C Smith Subject: Re: Yeelong and SiliconMotion driver: asking for developers On Wed, Mar 10, 2010 at 5:16 AM, Daniel Stone wrote: > Hi, > > On Wed, Mar 10, 2010 at 08:51:56AM +, Owain Ainsworth wrote: >> On Tue, Mar 09, 2010 at 10:22:28PM -0430, Octavio Rossell wrote: >> > The idea of this wiki: >> > http://gnu.org.ve/~octavio/lemote/doku.php?id=siliconmotiondriver >> > is to collect all info for makin this easy. If any of you have more >> > info or has a technical correction is ok (is on free editing mode) >> > but is only a space where to put the info with an universal scope. >> >> Can you please clarify what the comments about GPLv3 are supposed to >> mean on that page? Is it a reference to a non-public discussion? >> >> If the current driver is licensed under the MIT/X11 license (as it >> would appear that it is) changing it without adding substantial new >> work is legally questionable at best. Furthermore, changing this >> license after adding to it could be considered to be obnoxious and >> anti-community. > > Anyone's free to tack on a more restrictive license to their work, > which would bring the entire collection under the same license, but > yeah, it would be incredibly obnoxious. X.Org's does not (currently) > accept GPL packages anyway, so we couldn't merge it back. > > I heard vague rumblings about the FSF convincing Silicon Motion to > relicense it as GPLv3+ in private, with complete disregard for X.Org. > Good for the FSF: maybe they can do all the work on it then. I believe the issue there was that FSF needed some small subset of code dual-licensed to be able to incorporate it into GRUB2, which is GPLv3 - GRUB2 is very close to being able to be the only boot firmware on the actual hardware PLCC chip of the yeeloong, and of course would load before Xorg. I don't believe there is any intent to actually try to relicense X; as you are probably aware FSF has in the past helped the X project with licensing issues - http://www.fsf.org/news/thank-you-sgi - and knowing the people involved I sincerely doubt there is any intention to do anything that would splinter the Xorg codebase. -- Daniel JB Clark | http://pobox.com/~dclark | Activist; Owner \|/ FREEDOM -+-> INCLUDED ~ http://freedomincluded.com /|\ Free Software respecting hardware ~ Lemote Yeeloong reseller ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: what is "primary" refer to in visual
Am 16.03.2010 09:42, schrieb Zhang, Xing Z: > Hi experts: > From xlib manual, here are sentences for color: > > GrayScale is treated the same way as PseudoColor except that the *primary* > that drives the > screen is undefined. Thus, the client should always store the same value for > red, green, and > blue in the colormaps. > > TrueColor is treated the same way as DirectColor except that the colormap has > predefined, > read-only RGB values. These RGB values are server dependent but provide > linear or > near-linear ramps in each *primary*. > >I apologize for my bad English, I am confused by the word "primary". I > wonder what does > "primary" mean here? Thank you. You may find this link helpful: http://en.wikipedia.org/wiki/Primary_colour Cheers, Simon ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Yeelong and SiliconMotion driver: asking for developers
On Wed, Mar 10, 2010 at 5:16 AM, Daniel Stone wrote: > Hi, > > On Wed, Mar 10, 2010 at 08:51:56AM +, Owain Ainsworth wrote: >> On Tue, Mar 09, 2010 at 10:22:28PM -0430, Octavio Rossell wrote: >> > The idea of this wiki: >> > http://gnu.org.ve/~octavio/lemote/doku.php?id=siliconmotiondriver >> > is to collect all info for makin this easy. If any of you have more info >> > or has a technical correction is ok (is on free editing mode) but is >> > only a space where to put the info with an universal scope. >> >> Can you please clarify what the comments about GPLv3 are supposed to >> mean on that page? Is it a reference to a non-public discussion? >> >> If the current driver is licensed under the MIT/X11 license (as it would >> appear that it is) changing it without adding substantial new work is >> legally questionable at best. Furthermore, changing this license after >> adding to it could be considered to be obnoxious and anti-community. > > Anyone's free to tack on a more restrictive license to their work, which > would bring the entire collection under the same license, but yeah, it > would be incredibly obnoxious. X.Org's does not (currently) accept GPL > packages anyway, so we couldn't merge it back. > > I heard vague rumblings about the FSF convincing Silicon Motion to > relicense it as GPLv3+ in private, with complete disregard for X.Org. > Good for the FSF: maybe they can do all the work on it then. I believe the issue there was that FSF needed some small subset of code dual-licensed to be able to incorporate it into GRUB2, which is GPLv3 - GRUB2 is very close to being able to be the only boot firmware on the actual hardware PLCC chip of the yeeloong, and of course would load before Xorg. I don't believe there is any intent to actually try to relicense X; as you are probably aware FSF has in the past helped the X project with licensing issues - http://www.fsf.org/news/thank-you-sgi - and knowing the people involved I sincerely doubt there is any intention to do anything that would splinter the Xorg codebase. -- Daniel JB Clark | http://pobox.com/~dclark | Activist; Owner \|/ FREEDOM -+-> INCLUDED ~ http://freedomincluded.com /|\ Free Software respecting hardware ~ Lemote Yeeloong reseller ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Please help with Xorg
On 16.03.2010 02:50, John Tapsell wrote: > On 15 March 2010 20:03, Simone Azzalin wrote: >>>Just to eliminate the stupid questions first.. Is your screen TFT, and if so, what is its native resolution? :) >> Resolutions always worked fine with many distros, but in the last times it >> happens with recents distros for example.. >> The first resolution proposed is 1200 x 920 (if I remember well because I'm >> on another pc right now ) > > Okay so that's a ratio of 1200/920 = 5/4 = 1.25 > But you're trying to use a resolution of 1024/768 = 4/3 = 1.33 > > So it's no wonder you're getting black bars. The picture just doesn't > fit on the screen. > > If it used to 'work', probably you just set some setting on the > monitor to stretch the screen to fit, instead of adding black bars. > > So, either run in 1200/920 or play about with the monitor settings to > find a way to make it stretch instead of adding black bars. > > I think this has nothing to do with linux or xorg. Well if that's a notebook lvds panel, those don't come with scalers, hence the graphic chip does this. It may be adjustable with something like xrandr --output LVDS --set scale full or something like that. I agree though it's better to use native resolution (or one which at least has the same aspect ratio) if you don't want black bars. Roland ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: what is "primary" refer to in visual
Twas brillig at 16:42:51 16.03.2010 UTC+08 when xing.z.zh...@intel.com did gyre and gimble: ZXZ> GrayScale is treated the same way as PseudoColor except that the ZXZ> *primary* that drives the screen is undefined. Thus, the client ZXZ> should always store the same value for red, green, and blue in the ZXZ> colormaps. ZXZ> TrueColor is treated the same way as DirectColor except that the ZXZ> colormap has predefined, read-only RGB values. These RGB values ZXZ> are server dependent but provide linear or near-linear ramps in ZXZ> each *primary*. ZXZ> I apologize for my bad English, I am confused by the word ZXZ> "primary". I wonder what does "primary" mean here? Thank you. In this context it means one component of the R/G/B triad. So e.g. for GrayScale it is undefined will server use R, G or B component of colormap for a grayscale value. -- http://fossarchy.blogspot.com/ pgpnG3m9dRZXj.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
what is "primary" refer to in visual
Hi experts: From xlib manual, here are sentences for color: GrayScale is treated the same way as PseudoColor except that the *primary* that drives the screen is undefined. Thus, the client should always store the same value for red, green, and blue in the colormaps. TrueColor is treated the same way as DirectColor except that the colormap has predefined, read-only RGB values. These RGB values are server dependent but provide linear or near-linear ramps in each *primary*. I apologize for my bad English, I am confused by the word "primary". I wonder what does "primary" mean here? Thank you. Zhang Xin(Wing) Intel(SSG/OTC) ShangHai China ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
