Re: X.org plans for the lenny cycle
On Mon, Feb 11, 2008 at 03:06:57PM +1100, Niv Sardi wrote: > I forwarded that information internaly to my manager about a week ago > (after a discution with jcristeau), I believe that the message is: > * If it affects only Debian SGI (as a corporation) will not care and > treat us as a bunch of nitpickers hippies. > (julien sent me a link I can't find now where fedora seemed to state > that they had the same concerns) You probably won't find it. I had a private discussion with a RedHat employee who mentioned that their lawyers were interested in resolving issues with licenses like FreeB for practical reasons. I don't know exactly what became of it. Also of note is that Brett Smith from the FSF is working on this problem privately right now, and while he isn't able to report on any of the discussions publicly he does claim to be making some headway. > * It is possible that SGI doesn't own the code anymore (and that Khronos does) > > On Feb 11, 2008 2:20 PM, Aníbal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > > On Fri, Apr 13, 2007 at 12:46:30PM +1000, Drew Parsons wrote: > > >On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: > > >>On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: > > >>> > > >>>A long-standing bug which should be thought about is the GL licensing > > >>>problem [1]. SGI kindly contributed code for GL support in X, but their > > >>>licence is not DSFG. Upstream is not comfortable with the situation > > >>>either and there have been intentions to approach colleagues at SGI to > > Then we should contact SGI all together... > > > >>>see about rationalising the licence, to the common X11 licence or > > >>>otherwise. However these correspondences proceed at a glacial > > >>>corporate rate - not high on corporate SGI's TODO list, you might say. > > >>>We've conveniently been ignoring the problem for Debian stable, do we > > >>>continue doing so, or are we capable of prodding SGI to accelerate the > > >>>discussions? Or do we ditch OpenGL support from Debian... ? > > Please let's not make these kinds of calls,... Indeed. I don't see any benefit to doing something rash in this case. Outright removal of the code won't make it Free any faster, nor are there people lining up to reimplement it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
I forwarded that information internaly to my manager about a week ago (after a discution with jcristeau), I believe that the message is: * If it affects only Debian SGI (as a corporation) will not care and treat us as a bunch of nitpickers hippies. (julien sent me a link I can't find now where fedora seemed to state that they had the same concerns) * It is possible that SGI doesn't own the code anymore (and that Khronos does) On Feb 11, 2008 2:20 PM, Aníbal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > On Fri, Apr 13, 2007 at 12:46:30PM +1000, Drew Parsons wrote: > >On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: > >>On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: > >>> > >>>A long-standing bug which should be thought about is the GL licensing > >>>problem [1]. SGI kindly contributed code for GL support in X, but their > >>>licence is not DSFG. Upstream is not comfortable with the situation > >>>either and there have been intentions to approach colleagues at SGI to Then we should contact SGI all together... > >>>see about rationalising the licence, to the common X11 licence or > >>>otherwise. However these correspondences proceed at a glacial > >>>corporate rate - not high on corporate SGI's TODO list, you might say. > >>>We've conveniently been ignoring the problem for Debian stable, do we > >>>continue doing so, or are we capable of prodding SGI to accelerate the > >>>discussions? Or do we ditch OpenGL support from Debian... ? Please let's not make these kinds of calls,... -- Niv Sardi
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 12:46:30PM +1000, Drew Parsons wrote: >On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: >>On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: >>> >>>A long-standing bug which should be thought about is the GL licensing >>>problem [1]. SGI kindly contributed code for GL support in X, but their >>>licence is not DSFG. Upstream is not comfortable with the situation >>>either and there have been intentions to approach colleagues at SGI to >>>see about rationalising the licence, to the common X11 licence or >>>otherwise. However these correspondences proceed at a glacial >>>corporate rate - not high on corporate SGI's TODO list, you might say. >>>We've conveniently been ignoring the problem for Debian stable, do we >>>continue doing so, or are we capable of prodding SGI to accelerate the >>>discussions? Or do we ditch OpenGL support from Debian... ? >> >>I'm currently working for SGI (together with Russell Coker, in the >>same project). Russell doesn't work for SGI any more. But Niv is. I've cc-ed Jim and Niv. >>>Drew >>> >>>[1] bugs #368560, #368559, #211765 (I think this one is redundant, the >>>original bug mitosed into the others) and #368564 >> >>Aníbal Monsalve Salazar > >That sounds promising! It would be an Honourable Task if you and >Russell could find who's responsible for the GL licences and get the >inconsistency wiped. There are fears SGI is no longer in control of the >code [1]. On the X.org side it was Jim Gettys who was going to try to >work on the licence problems [2]. No doubt worth liasing with him if >you're able to proceed with this task. Jim, what could Niv and I do from inside SGI? >Drew > > >[1] http://lists.freedesktop.org/archives/xorg/2006-December/020397.html >http://lists.freedesktop.org/archives/xorg/2006-December/020422.html > >[2] http://lists.freedesktop.org/archives/xorg/2006-October/018648.html signature.asc Description: Digital signature
Re: -ati driver (was: X.org plans for the lenny cycle)
Le dimanche 15 avril 2007 à 22:29 +0200, Brice Goglin a écrit : > Josip Rodin wrote: > > BTW, is there any chance that the -ati driver is going to include support > > for newer cards, the Radeon X series? It's sort of pointless for any newer > > machine, it won't even start X... > > > > Dave Airlie did some work on R500 last year, but he was waiting for > ATI's approval before releasing anything. See > http://airlied.livejournal.com/31180.html . I didn't hear of anything > new about this since then. ISTR he got an informal answer from an ATI guy basically saying he'll never have the green light from ATI. Sad. Xav
-ati driver (was: X.org plans for the lenny cycle)
Josip Rodin wrote: > BTW, is there any chance that the -ati driver is going to include support > for newer cards, the Radeon X series? It's sort of pointless for any newer > machine, it won't even start X... > Dave Airlie did some work on R500 last year, but he was waiting for ATI's approval before releasing anything. See http://airlied.livejournal.com/31180.html . I didn't hear of anything new about this since then. On the
Re: X.org plans for the lenny cycle
El Sábado, 14 de Abril de 2007, Noah Meyerhans escribió: > On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: > > These are a real thorn in our sides. Another issue is the nvidia code > > obfuscation bug, which we can fix when we get nouveau in to the archive. > > I'd love to have a dedicated maintainer for nouveau[0], but right now > > it's looking like I need to buy myself an nvidia card. Either way, that > > etch-ignore bug will be fixable for lenny thanks to the upstream work. > > > > - David Nusinow > > > > [0] Anyone who's interested, *please* write us at debian-x. We'd love to > > help you get going on this. > > I may be able to help here. At work, we've got ~300 Debian > workstations, almost all of which use either ATI or nvidia graphics > hardware, so I've got extensive hardware resources at my disposal. > > I'm not currently up to speed the state of neuveau development, so I > can't jump right in and get to work, but I should be able to get > involved reasonably quickly. > > Have there been any attempts thus far at packaging neuveau? Where are > they? I was going to reply to David's mail as well, but you were faster. :-) I was wondering some days ago if that could be possible. The thing that I wanted to do now, given there is no official release from nouveau was to create snapshots from Mesa/freedesktop/drm-kernel-module until stability arrive to the branch. I have some drafts in my home computer trying to take shape in packages. Best regards, Ender. -- El conceto es el conceto. -- Pazos (Airbag). -- Área de Internet - Network services Mundinteractivos - El Mundo C/Pradillo, 42 - Madrid (Spain) -- El conceto es el conceto. -- Pazos (Airbag). -- Desarrollador de Debian Debian developer pgp6zWZs1KWl7.pgp Description: PGP signature
Re: X.org plans for the lenny cycle
On Sun, Apr 15, 2007 at 12:24:24PM +0200, Josip Rodin wrote: > BTW, is there any chance that the -ati driver is going to include support > for newer cards, the Radeon X series? It's sort of pointless for any newer > machine, it won't even start X... The problem is that the newer cards have dramatically changed how they do 2D, and as far as I know, no one has started reverse engineering them to make them work. So you're basically stuck with fglrx in that situation. It's a sucky place to be in, but I don't ha ve a better answer for you. > I recently actually got sufficiently pissed off at both the ati and fglrx > drivers that I went out and bought an nv/nvidia card, both of whose drivers > actually work properly. Yeah, not an uncommon thing to hear unfortunately. With Intel looking to put out stand-alone video cards soon, and with nouveau hopefully picking up its stride, things should improve somewhat for the ati alternatives. It's sad to see what's become of ati though. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: > > 1) active probing of video cards to allow a more dynamic setting and > > resetting of video modes used. This work is mostly complete already > > (available in experimental xserver-xorg-video-intel, soon to appear in > > unstable). > > To expand on Drew's excellent summary further, there is support in a > development branch for the -ati driver for this as well, but it's not ready > yet. BTW, is there any chance that the -ati driver is going to include support for newer cards, the Radeon X series? It's sort of pointless for any newer machine, it won't even start X... I recently actually got sufficiently pissed off at both the ati and fglrx drivers that I went out and bought an nv/nvidia card, both of whose drivers actually work properly. (Please Cc: responses, I'm not subscribed to -x.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 11:09:41AM -0400, Noah Meyerhans wrote: > On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: > > These are a real thorn in our sides. Another issue is the nvidia code > > obfuscation bug, which we can fix when we get nouveau in to the archive. > > I'd love to have a dedicated maintainer for nouveau[0], but right now it's > > looking like I need to buy myself an nvidia card. Either way, that > > etch-ignore bug will be fixable for lenny thanks to the upstream work. > > > > - David Nusinow > > > > [0] Anyone who's interested, *please* write us at debian-x. We'd love to > > help you get going on this. > > I may be able to help here. At work, we've got ~300 Debian > workstations, almost all of which use either ATI or nvidia graphics > hardware, so I've got extensive hardware resources at my disposal. That would be awesome! > I'm not currently up to speed the state of neuveau development, so I > can't jump right in and get to work, but I should be able to get > involved reasonably quickly. Ok, I haven't been tracking things as closely either, so I basically hear about milestones when they happen. > Have there been any attempts thus far at packaging neuveau? Where are > they? Not that I'm aware of, but it shouldn't be hard to adapt our current driver packaging to nouveau. It's relatively simple packaging, although we do have a lot of extra stuff bolted on that will hopefully be mostly going away during this release cycle. As for nouveau itself, it may need a more up to date libdrm and mesa than we currently have, although once we get 7.2 in to unstable then experimental can be a playground for that. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X.org plans for the lenny cycle
On Sat, Apr 14, 2007 at 10:25:31AM -0400, David Nusinow wrote: > These are a real thorn in our sides. Another issue is the nvidia code > obfuscation bug, which we can fix when we get nouveau in to the archive. > I'd love to have a dedicated maintainer for nouveau[0], but right now it's > looking like I need to buy myself an nvidia card. Either way, that > etch-ignore bug will be fixable for lenny thanks to the upstream work. > > - David Nusinow > > [0] Anyone who's interested, *please* write us at debian-x. We'd love to > help you get going on this. I may be able to help here. At work, we've got ~300 Debian workstations, almost all of which use either ATI or nvidia graphics hardware, so I've got extensive hardware resources at my disposal. I'm not currently up to speed the state of neuveau development, so I can't jump right in and get to work, but I should be able to get involved reasonably quickly. Have there been any attempts thus far at packaging neuveau? Where are they? noah signature.asc Description: Digital signature
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: > Marc 'HE' Brockschmidt enquired: > > The release team is currently working on a schedule for the lenny > > release cycle. For that, we want to gather some data from the bigger > > software packaging teams in Debian first. > > > > We would like to know which major upstream versions of X.org are > > expected to be released in the next 24 months and how much time you > > expect them to need to get stable enough for a Debian stable release. > > > > Our current, very rough plans would mean a release in 18 months, which > > would be in October 2008. We expect to shuffle this a bit around to fit > > everyone's needs, so please tell us if this date works for you. > > As I see it, there are three major developments going on in X.org at > the moment. > > 1) active probing of video cards to allow a more dynamic setting and > resetting of video modes used. This work is mostly complete already > (available in experimental xserver-xorg-video-intel, soon to appear in > unstable). To expand on Drew's excellent summary further, there is support in a development branch for the -ati driver for this as well, but it's not ready yet. I expect it to be ready in time for lenny. Nouveau, the replacement for -nv, which is in development will also have support for this, which covers all the major chipsets in use today. I wouldn't be surprised if we see several other drivers that are being actively maintained use this. As it is, this goal is flexible, and we'll ship the best support that's available when lenny is ready. For any chips that aren't ready, they can use the current architecture we already have in place. > 2) Support for input-hotplug. As with the dynamic modesetting in 1), > this allows for dynamic plugging in of X-related devices. Currently > being developed on the master X.org branch, should be ready in X11R7.3 > by June or July. It's not clear what's goin on with this. The implementation requires a daemon which talks to HAL via dbus and lets the X server know when a device changes. Currently, there's a prototype implementation in C written by Daniel Stone, which isn't really meant for production use. There's also an implementation in Python written by a Gentoo developer which is probably also not ready. Once we get 7.2 in to unstable, we'll have to make a more serious run at this. Even if it's not ready to turn on by default though, I plan to follow upstream and set the default mouse to /dev/input/mice, which will solve most problems and simplify things for our users. So either way, the release team shouldn't have to worry about things from this end. Expect to see more from us on it in the coming few months though. > 3) More generally, making /etc/X11/xorg.conf completely redundant. I > believe this will not be achieved under 2), but is a longer term goal. I'm actively working on this with upstream, albeit slowly. The infrastructure is in place to run without a xorg.conf completely, but it doesn't work properly when you have to change something. I'm in the process of making this work so that we can ship without a xorg.conf, or with a minimal one that only changes what the user needs. The exact shape of this by the end of the lenny cycle isn't really possible to predict (and it depends on the improved resolution stuff in item 1) but we can at least whittle away at this as the lenny cycle goes on so that we don't cause any disruptions to the release while making the improvements. > As you can see, X.org's broad aims at the moment are to improve > usability by enabling the Xserver to be configured automatically > without user intervention. X.org is striving to keep to a relatively > strict six month release cycle, I would imagine six months is > sufficient time for us to stabilise X for the release of Lenny. So > with a goal of Oct 2008 we would expect to include X11R7.4, which > should have been released around Feb or Mar 2008. This would include > the new input-hotplug features. One thing the XSF needs to do is actively build the packaging infrastructure for the input-hotplugging. I'm not sure exactly how long this will take, but I don't imagine that it will be too difficult. > A long-standing bug which should be thought about is the GL licensing > problem [1]. SGI kindly contributed code for GL support in X, but their > licence is not DSFG. Upstream is not comfortable with the situation > either and there have been intentions to approach colleagues at SGI to > see about rationalising the licence, to the common X11 licence or > otherwise. However these correspondences proceed at a glacial > corporate rate - not high on corporate SGI's TODO list, you might say. > We've conveniently been ignoring the problem for Debian stable, do we > continue doing so, or are we capable of prodding SGI to accelerate the > discussions? Or do we ditch OpenGL support from Debian... ? These are a real thorn in our sides. Another issue is the nvidia code ob
Re: X.org plans for the lenny cycle
On Fri, 2007-04-13 at 11:38 +1000, Aníbal Monsalve Salazar wrote: > On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: > > > >A long-standing bug which should be thought about is the GL licensing > >problem [1]. SGI kindly contributed code for GL support in X, but their > >licence is not DSFG. Upstream is not comfortable with the situation > >either and there have been intentions to approach colleagues at SGI to > >see about rationalising the licence, to the common X11 licence or > >otherwise. However these correspondences proceed at a glacial > >corporate rate - not high on corporate SGI's TODO list, you might say. > >We've conveniently been ignoring the problem for Debian stable, do we > >continue doing so, or are we capable of prodding SGI to accelerate the > >discussions? Or do we ditch OpenGL support from Debian... ? > > I'm currently working for SGI (together with Russell Coker, in the > same project). > > >Drew > > > >[1] bugs #368560, #368559, #211765 (I think this one is redundant, the > >original bug mitosed into the others) and #368564 > > Aníbal Monsalve Salazar That sounds promising! It would be an Honourable Task if you and Russell could find who's responsible for the GL licences and get the inconsistency wiped. There are fears SGI is no longer in control of the code [1]. On the X.org side it was Jim Gettys who was going to try to work on the licence problems [2]. No doubt worth liasing with him if you're able to proceed with this task. Drew [1] http://lists.freedesktop.org/archives/xorg/2006-December/020397.html http://lists.freedesktop.org/archives/xorg/2006-December/020422.html [2] http://lists.freedesktop.org/archives/xorg/2006-October/018648.html
Re: X.org plans for the lenny cycle
On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: >Marc 'HE' Brockschmidt enquired: >>The release team is currently working on a schedule for the lenny >>release cycle. For that, we want to gather some data from the bigger >>software packaging teams in Debian first. >> >>We would like to know which major upstream versions of X.org are >>expected to be released in the next 24 months and how much time you >>expect them to need to get stable enough for a Debian stable release. >> >>Our current, very rough plans would mean a release in 18 months, which >>would be in October 2008. We expect to shuffle this a bit around to fit >>everyone's needs, so please tell us if this date works for you. > >As I see it, there are three major developments going on in X.org at >the moment. > >1) active probing of video cards to allow a more dynamic setting and >resetting of video modes used. This work is mostly complete already >(available in experimental xserver-xorg-video-intel, soon to appear in >unstable). > >2) Support for input-hotplug. As with the dynamic modesetting in 1), >this allows for dynamic plugging in of X-related devices. Currently >being developed on the master X.org branch, should be ready in X11R7.3 >by June or July. > >3) More generally, making /etc/X11/xorg.conf completely redundant. I >believe this will not be achieved under 2), but is a longer term goal. > >As you can see, X.org's broad aims at the moment are to improve >usability by enabling the Xserver to be configured automatically >without user intervention. X.org is striving to keep to a relatively >strict six month release cycle, I would imagine six months is >sufficient time for us to stabilise X for the release of Lenny. So >with a goal of Oct 2008 we would expect to include X11R7.4, which >should have been released around Feb or Mar 2008. This would include >the new input-hotplug features. > >A long-standing bug which should be thought about is the GL licensing >problem [1]. SGI kindly contributed code for GL support in X, but their >licence is not DSFG. Upstream is not comfortable with the situation >either and there have been intentions to approach colleagues at SGI to >see about rationalising the licence, to the common X11 licence or >otherwise. However these correspondences proceed at a glacial >corporate rate - not high on corporate SGI's TODO list, you might say. >We've conveniently been ignoring the problem for Debian stable, do we >continue doing so, or are we capable of prodding SGI to accelerate the >discussions? Or do we ditch OpenGL support from Debian... ? I'm currently working for SGI (together with Russell Coker, in the same project). >Drew > >[1] bugs #368560, #368559, #211765 (I think this one is redundant, the >original bug mitosed into the others) and #368564 Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: X.org plans for the lenny cycle
Marc 'HE' Brockschmidt enquired: > The release team is currently working on a schedule for the lenny > release cycle. For that, we want to gather some data from the bigger > software packaging teams in Debian first. > > We would like to know which major upstream versions of X.org are > expected to be released in the next 24 months and how much time you > expect them to need to get stable enough for a Debian stable release. > > Our current, very rough plans would mean a release in 18 months, which > would be in October 2008. We expect to shuffle this a bit around to fit > everyone's needs, so please tell us if this date works for you. As I see it, there are three major developments going on in X.org at the moment. 1) active probing of video cards to allow a more dynamic setting and resetting of video modes used. This work is mostly complete already (available in experimental xserver-xorg-video-intel, soon to appear in unstable). 2) Support for input-hotplug. As with the dynamic modesetting in 1), this allows for dynamic plugging in of X-related devices. Currently being developed on the master X.org branch, should be ready in X11R7.3 by June or July. 3) More generally, making /etc/X11/xorg.conf completely redundant. I believe this will not be achieved under 2), but is a longer term goal. As you can see, X.org's broad aims at the moment are to improve usability by enabling the Xserver to be configured automatically without user intervention. X.org is striving to keep to a relatively strict six month release cycle, I would imagine six months is sufficient time for us to stabilise X for the release of Lenny. So with a goal of Oct 2008 we would expect to include X11R7.4, which should have been released around Feb or Mar 2008. This would include the new input-hotplug features. A long-standing bug which should be thought about is the GL licensing problem [1]. SGI kindly contributed code for GL support in X, but their licence is not DSFG. Upstream is not comfortable with the situation either and there have been intentions to approach colleagues at SGI to see about rationalising the licence, to the common X11 licence or otherwise. However these correspondences proceed at a glacial corporate rate - not high on corporate SGI's TODO list, you might say. We've conveniently been ignoring the problem for Debian stable, do we continue doing so, or are we capable of prodding SGI to accelerate the discussions? Or do we ditch OpenGL support from Debian... ? Drew [1] bugs #368560, #368559, #211765 (I think this one is redundant, the original bug mitosed into the others) and #368564 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
X.org plans for the lenny cycle
Heya, The release team is currently working on a schedule for the lenny release cycle. For that, we want to gather some data from the bigger software packaging teams in Debian first. We would like to know which major upstream versions of X.org are expected to be released in the next 24 months and how much time you expect them to need to get stable enough for a Debian stable release. Our current, very rough plans would mean a release in 18 months, which would be in October 2008. We expect to shuffle this a bit around to fit everyone's needs, so please tell us if this date works for you. Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
