From: Dave A. <ai...@gm...> - 2008-02-28 06:53:51
|
So just to let people know where kernel modesetting is getting to and what I'm up to with it.. So I really want to ship something in Fedora 9 with kernel modesetting in it, whether this is a default or a special boot option for the user I won't decide for a while. But with this in mind I've checked in bunch of changes to the modesetting drm to make modesetting optional for i915, you now load the i915 module with modeset=1 to enable it. I've also created an intel-kernelmode branch which is based on the intel-batchbuffer branch, with fairly clean modesetting integration. It still needs work to fixup a few features but I'm going to work my way through the list. (it needs fixes for rotation + video at the moment) The DDX driver can detect whether modesetting is enabled in the drm and does the right thing for each case. I checked a patch into the server to allow the crtc callback to work, I think this breaks ABI with xf86Crtc.c users, need to confirm what the proper action for this is. Dave. |
From: Maarten M. <mad...@gm...> - 2008-02-28 12:36:02
|
On 2/28/08, Dave Airlie <ai...@gm...> wrote: > So just to let people know where kernel modesetting is getting to and > what I'm up to with it.. > > So I really want to ship something in Fedora 9 with kernel modesetting > in it, whether this is a default or a special boot option for the user > I won't decide for a while. > > But with this in mind I've checked in bunch of changes to the > modesetting drm to make modesetting optional for i915, you now load > the i915 module with modeset=1 to enable it. > I've also created an intel-kernelmode branch which is based on the > intel-batchbuffer branch, with fairly clean modesetting integration. > It still needs work to fixup a few features but I'm going to work my > way through the list. > (it needs fixes for rotation + video at the moment) > > The DDX driver can detect whether modesetting is enabled in the drm > and does the right thing for each case. > > I checked a patch into the server to allow the crtc callback to work, > I think this breaks ABI with xf86Crtc.c users, need to confirm what > the proper action for this is. I can confirm that i had to recompile my video driver after upgrading the xserver. The problem was obscure (a blank screen) and not some hard failure. > > Dave. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Jerome G. <gl...@fr...> - 2008-02-28 13:36:34
|
On Thu, 28 Feb 2008 16:53:46 +1000 "Dave Airlie" <ai...@gm...> wrote: > So just to let people know where kernel modesetting is getting to and > what I'm up to with it.. > > So I really want to ship something in Fedora 9 with kernel modesetting > in it, whether this is a default or a special boot option for the user > I won't decide for a while. > > But with this in mind I've checked in bunch of changes to the > modesetting drm to make modesetting optional for i915, you now load > the i915 module with modeset=1 to enable it. > I've also created an intel-kernelmode branch which is based on the > intel-batchbuffer branch, with fairly clean modesetting integration. > It still needs work to fixup a few features but I'm going to work my > way through the list. > (it needs fixes for rotation + video at the moment) > > The DDX driver can detect whether modesetting is enabled in the drm > and does the right thing for each case. > > I checked a patch into the server to allow the crtc callback to work, > I think this breaks ABI with xf86Crtc.c users, need to confirm what > the proper action for this is. > > Dave. Dave there is one things that is needed to be redone: frame buffer creation & handling. And i would like we not freeze the API until we had some time to play with it a bit. So i guess my question is does this means modesetting API get freezed or not ? For frame buffer create i believe we need some kind of properties system where userspace can ask for driver specific properties at creation time. Also we need a way to allow to query the actual framebuffer properties (ie one asked at creation might not work and driver can adjust them so userspace have to requery properties to know what have been done). I also would like the BO argument to become optional ie if none is supplied it's up to the driver to allocate a BO which fit with the asked properties. Corollary frame buffer creation can fail if supplied BO ain't big enough for the asked framebuffer properties. Finaly i am wondering if we should not provide some way to update & get part of the framebuffer this could be especialy usefull in case of dumb userspace which can't understand framebuffer properties and if we ever have hw which can't have linear framebuffer but need to store it in some strange format (maybe embedded device already fall in this category). Oh and modesetting can refuse to set mode if supplied framebuffer don't fit conditions. Cheers, Jerome Glisse |
From: Alex D. <ale...@gm...> - 2008-02-28 15:36:22
|
On Thu, Feb 28, 2008 at 1:53 AM, Dave Airlie <ai...@gm...> wrote: > So just to let people know where kernel modesetting is getting to and > what I'm up to with it.. > > So I really want to ship something in Fedora 9 with kernel modesetting > in it, whether this is a default or a special boot option for the user > I won't decide for a while. > > But with this in mind I've checked in bunch of changes to the > modesetting drm to make modesetting optional for i915, you now load > the i915 module with modeset=1 to enable it. > I've also created an intel-kernelmode branch which is based on the > intel-batchbuffer branch, with fairly clean modesetting integration. > It still needs work to fixup a few features but I'm going to work my > way through the list. > (it needs fixes for rotation + video at the moment) > > The DDX driver can detect whether modesetting is enabled in the drm > and does the right thing for each case. > > I checked a patch into the server to allow the crtc callback to work, > I think this breaks ABI with xf86Crtc.c users, need to confirm what > the proper action for this is. I think it would also be nice to add some additional abstraction to deal with outputs that have multiple encoders associated with them (e.g., DVI-I). Although as discussed previously, we can probably just add internal abstraction and add output controls to deal with this. Alex |
From: Maarten M. <mad...@gm...> - 2008-02-28 15:43:20
|
On 2/28/08, Dave Airlie <ai...@gm...> wrote: > So just to let people know where kernel modesetting is getting to and > what I'm up to with it.. > > So I really want to ship something in Fedora 9 with kernel modesetting > in it, whether this is a default or a special boot option for the user > I won't decide for a while. > > But with this in mind I've checked in bunch of changes to the > modesetting drm to make modesetting optional for i915, you now load > the i915 module with modeset=1 to enable it. > I've also created an intel-kernelmode branch which is based on the > intel-batchbuffer branch, with fairly clean modesetting integration. > It still needs work to fixup a few features but I'm going to work my > way through the list. > (it needs fixes for rotation + video at the moment) > > The DDX driver can detect whether modesetting is enabled in the drm > and does the right thing for each case. > > I checked a patch into the server to allow the crtc callback to work, > I think this breaks ABI with xf86Crtc.c users, need to confirm what > the proper action for this is. > > Dave. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > Please don't let any api freezing depend on fedora core, at least give external parties time to play with it once it's reasonably stable, this will undoubtely reveal limitations. It should be in mainline drm well before api freezing it. |
From: Jakob B. <wal...@gm...> - 2008-02-28 18:12:10
|
On Thu, Feb 28, 2008 at 2:36 PM, Jerome Glisse <gl...@fr...> wrote: > On Thu, 28 Feb 2008 16:53:46 +1000 > > "Dave Airlie" <ai...@gm...> wrote: > > > > So just to let people know where kernel modesetting is getting to and > > what I'm up to with it.. > > > > So I really want to ship something in Fedora 9 with kernel modesetting > > in it, whether this is a default or a special boot option for the user > > I won't decide for a while. > > > > But with this in mind I've checked in bunch of changes to the > > modesetting drm to make modesetting optional for i915, you now load > > the i915 module with modeset=1 to enable it. > > I've also created an intel-kernelmode branch which is based on the > > intel-batchbuffer branch, with fairly clean modesetting integration. > > It still needs work to fixup a few features but I'm going to work my > > way through the list. > > (it needs fixes for rotation + video at the moment) > > > > The DDX driver can detect whether modesetting is enabled in the drm > > and does the right thing for each case. > > > > I checked a patch into the server to allow the crtc callback to work, > > I think this breaks ABI with xf86Crtc.c users, need to confirm what > > the proper action for this is. > > > > Dave. > > Dave there is one things that is needed to be redone: frame buffer > creation & handling. And i would like we not freeze the API until > we had some time to play with it a bit. So i guess my question is > does this means modesetting API get freezed or not ? > > For frame buffer create i believe we need some kind of properties > system where userspace can ask for driver specific properties at > creation time. Also we need a way to allow to query the actual > framebuffer properties (ie one asked at creation might not work > and driver can adjust them so userspace have to requery properties > to know what have been done). I'm guessing a flag system could be used, sorta like the BO flags. There are some things to consider: should we allow driver dependant flags on it or should those be exposed in a driver specific ioctl. Also do we want a offset property? So we can have two framebuffers in one buffer or just not the start of it. > I also would like the BO argument to become optional ie if none > is supplied it's up to the driver to allocate a BO which fit > with the asked properties. Corollary frame buffer creation can > fail if supplied BO ain't big enough for the asked framebuffer > properties. It sounds like its just a convenience. If the driver creates it who owns it? There is also the question of reference on the buffer? Does the driver up the reference if it creates it? > Finaly i am wondering if we should not provide some way to > update & get part of the framebuffer this could be especialy > usefull in case of dumb userspace which can't understand > framebuffer properties and if we ever have hw which can't have > linear framebuffer but need to store it in some strange > format (maybe embedded device already fall in this category). Dumb userspace shouldn't be able to create tiled or none linear framebuffers, so its not realy a problem. I'm sure there are some crazy hardware which doesn't support linear framebuffers rgb buffers, the GameCube/Wii being one(two) of them. This is the dreaded acceleration api in kernel that nobody wants but everybody does anyways. What I mean by that is that all drivers has a function to speed up clearing memory regions and copy memory between vram and agp, it takes very little work to make those general for fill and copy. > Oh and modesetting can refuse to set mode if supplied framebuffer > don't fit conditions. I'm pretty sure the code does this now. > Cheers, > Jerome Glisse Cheers Jakob. PS: Sorry Jerome, silly gmail doesn't reply to all per default. |
From: Jerome G. <gl...@fr...> - 2008-02-28 22:22:00
|
On Thu, 28 Feb 2008 19:12:07 +0100 "Jakob Bornecrantz" <wal...@gm...> wrote: > > I'm guessing a flag system could be used, sorta like the BO flags. > There are some things to consider: should we allow driver dependant flags on it > or should those be exposed in a driver specific ioctl. > > Also do we want a offset property? So we can have two framebuffers in > one buffer or just not the start of it. I fear that flag system might be to limited for future case we might have. I would rather have driver specific properites how we do it is still open question but it needs to be supplied at framebuffer creation (well at least this what makes more sense to me). > > > I also would like the BO argument to become optional ie if none > > is supplied it's up to the driver to allocate a BO which fit > > with the asked properties. Corollary frame buffer creation can > > fail if supplied BO ain't big enough for the asked framebuffer > > properties. > > It sounds like its just a convenience. If the driver creates it who > owns it? There is also the question of reference on the buffer? Does > the driver up the reference if it creates it? I was thinking to that just for having an easier userspace as the create framebuffer should check bo size it will have the code necessary to compute this size. > > Finaly i am wondering if we should not provide some way to > > update & get part of the framebuffer this could be especialy > > usefull in case of dumb userspace which can't understand > > framebuffer properties and if we ever have hw which can't have > > linear framebuffer but need to store it in some strange > > format (maybe embedded device already fall in this category). > > Dumb userspace shouldn't be able to create tiled or none linear > framebuffers, so its not realy a problem. I'm sure there are some > crazy hardware which doesn't support linear framebuffers rgb buffers, > the GameCube/Wii being one(two) of them. > > This is the dreaded acceleration api in kernel that nobody wants but > everybody does anyways. What I mean by that is that all drivers has a > function to speed up clearing memory regions and copy memory between > vram and agp, it takes very little work to make those general for fill > and copy. I am thinking to device which can't have linear framebuffer. > > Oh and modesetting can refuse to set mode if supplied framebuffer > > don't fit conditions. > > I'm pretty sure the code does this now. Once we have properties like tiling there might be new case where we should refuse framebuffer (for instance on radeon tiling can't be activated with some video mode). Cheers, Jerome Glisse <gl...@fr...> |
From: Dave A. <ai...@gm...> - 2008-02-28 19:33:06
|
On Fri, Feb 29, 2008 at 1:36 AM, Alex Deucher <ale...@gm...> wrote: > > On Thu, Feb 28, 2008 at 1:53 AM, Dave Airlie <ai...@gm...> wrote: > > So just to let people know where kernel modesetting is getting to and > > what I'm up to with it.. > > > > So I really want to ship something in Fedora 9 with kernel modesetting > > in it, whether this is a default or a special boot option for the user > > I won't decide for a while. > > > > But with this in mind I've checked in bunch of changes to the > > modesetting drm to make modesetting optional for i915, you now load > > the i915 module with modeset=1 to enable it. > > I've also created an intel-kernelmode branch which is based on the > > intel-batchbuffer branch, with fairly clean modesetting integration. > > It still needs work to fixup a few features but I'm going to work my > > way through the list. > > (it needs fixes for rotation + video at the moment) > > > > The DDX driver can detect whether modesetting is enabled in the drm > > and does the right thing for each case. > > > > I checked a patch into the server to allow the crtc callback to work, > > I think this breaks ABI with xf86Crtc.c users, need to confirm what > > the proper action for this is. > > I think it would also be nice to add some additional abstraction to > deal with outputs that have multiple encoders associated with them > (e.g., DVI-I). Although as discussed previously, we can probably just > add internal abstraction and add output controls to deal with this. > the current API abstracts connectors from outputs, so in reality it is encoders with connector properties at the moment. you define a connector type and a connector id for each output and can gang them together.. so wrt to the kernel API, output == encoder, output != connector. the kernel API also contains no names just enums. Dave. |
From: Dave A. <ai...@gm...> - 2008-02-28 19:36:25
|
> Please don't let any api freezing depend on fedora core, at least give > external parties time to play with it once it's reasonably stable, > this will undoubtely reveal limitations. It should be in mainline drm > well before api freezing it. > It's not called Fedora core any more :), but I won't be setting the API in stone, I'll just be having people justify themselves for changing it.. Who are these external parties you speak off? if they aren't involved with X.org development then I don't really care... please try and play with the API now, you completely contradict yourself in that statement, how I can it be reasonably stable if you expect it to be full of limitations? But in any case don't worry the API won't be frozen I'll deal with the hit in Fedora... Dave. |
From: Maarten M. <mad...@gm...> - 2008-02-28 21:39:20
|
On 2/28/08, Dave Airlie <ai...@gm...> wrote: > > Please don't let any api freezing depend on fedora core, at least give > > external parties time to play with it once it's reasonably stable, > > this will undoubtely reveal limitations. It should be in mainline drm > > well before api freezing it. > > > > > It's not called Fedora core any more :), but I won't be setting the > API in stone, I'll just be having people justify themselves for > changing it.. > > Who are these external parties you speak off? if they aren't involved > with X.org development then I don't really care... please try and play > with the API > now, you completely contradict yourself in that statement, how I can > it be reasonably stable if you expect it to be full of limitations? Those external parties would refer to me. My original intention was to wait for a feature complete api (something in mainline drm), because i simply do not have the time to "play around" with it, nor is the porting a trivial effort. I would be surprised if everything was perfect from the start. > But in any case don't worry the API won't be frozen I'll deal with the > hit in Fedora... > > > Dave. > |
From: Jesse B. <jb...@vi...> - 2008-02-28 21:04:35
|
On Thursday, February 28, 2008 5:36 am Jerome Glisse wrote: > Dave there is one things that is needed to be redone: frame buffer > creation & handling. And i would like we not freeze the API until > we had some time to play with it a bit. So i guess my question is > does this means modesetting API get freezed or not ? > > For frame buffer create i believe we need some kind of properties > system where userspace can ask for driver specific properties at > creation time. Also we need a way to allow to query the actual > framebuffer properties (ie one asked at creation might not work > and driver can adjust them so userspace have to requery properties > to know what have been done). What kind of properties did you have in mind? Why aren't the regular BO flags enough? Were you thinking of fence register allocation for tiled regions or something? > I also would like the BO argument to become optional ie if none > is supplied it's up to the driver to allocate a BO which fit > with the asked properties. Corollary frame buffer creation can > fail if supplied BO ain't big enough for the asked framebuffer > properties. Yeah, that should probably -EINVAL. > Finaly i am wondering if we should not provide some way to > update & get part of the framebuffer this could be especialy > usefull in case of dumb userspace which can't understand > framebuffer properties and if we ever have hw which can't have > linear framebuffer but need to store it in some strange > format (maybe embedded device already fall in this category). I guess you're thinking of the types of devices that use shadowfb now then upload the finished framebuffer into banked memory or whatever? Thanks, Jesse |
From: Jesse B. <jb...@vi...> - 2008-02-28 21:27:05
|
On Thursday, February 28, 2008 11:33 am Dave Airlie wrote: > the current API abstracts connectors from outputs, so in reality it > is encoders with connector properties at the moment. > > you define a connector type and a connector id for each output and > can gang them together.. > > so wrt to the kernel API, output == encoder, output != connector. the > kernel API also contains no names just enums. Maybe we should rename things internally to avoid confusion... Jesse |
From: Jerome G. <gl...@fr...> - 2008-02-28 22:24:44
|
On Thu, 28 Feb 2008 12:48:55 -0800 Jesse Barnes <jb...@vi...> wrote: > On Thursday, February 28, 2008 5:36 am Jerome Glisse wrote: > > Dave there is one things that is needed to be redone: frame buffer > > creation & handling. And i would like we not freeze the API until > > we had some time to play with it a bit. So i guess my question is > > does this means modesetting API get freezed or not ? > > > > For frame buffer create i believe we need some kind of properties > > system where userspace can ask for driver specific properties at > > creation time. Also we need a way to allow to query the actual > > framebuffer properties (ie one asked at creation might not work > > and driver can adjust them so userspace have to requery properties > > to know what have been done). > > What kind of properties did you have in mind? Why aren't the regular BO > flags enough? Were you thinking of fence register allocation for tiled > regions or something? We already discussed about on IRC and maybe mailing list :) but i believe the outcome is that we don't touch BO. Yet i feel that we need to have the framebuffer properties (tiling, compression, weird storage format) in a driver dependant way somewhere along the framebuffer object and that userspace should be able to query this properties to know (if userspace clever enough) how to access the framebuffer or simply to properly format blit command. > > I also would like the BO argument to become optional ie if none > > is supplied it's up to the driver to allocate a BO which fit > > with the asked properties. Corollary frame buffer creation can > > fail if supplied BO ain't big enough for the asked framebuffer > > properties. > > Yeah, that should probably -EINVAL. > > > Finaly i am wondering if we should not provide some way to > > update & get part of the framebuffer this could be especialy > > usefull in case of dumb userspace which can't understand > > framebuffer properties and if we ever have hw which can't have > > linear framebuffer but need to store it in some strange > > format (maybe embedded device already fall in this category). > > I guess you're thinking of the types of devices that use shadowfb now > then upload the finished framebuffer into banked memory or whatever? Yes to that kind of device, and others that might appear in the future. Cheers, Jerome Glisse <gl...@fr...> |
From: Alex D. <ale...@gm...> - 2008-02-28 23:22:08
|
On Thu, Feb 28, 2008 at 5:24 PM, Jerome Glisse <gl...@fr...> wrote: > On Thu, 28 Feb 2008 12:48:55 -0800 > Jesse Barnes <jb...@vi...> wrote: > > > On Thursday, February 28, 2008 5:36 am Jerome Glisse wrote: > > > Dave there is one things that is needed to be redone: frame buffer > > > creation & handling. And i would like we not freeze the API until > > > we had some time to play with it a bit. So i guess my question is > > > does this means modesetting API get freezed or not ? > > > > > > For frame buffer create i believe we need some kind of properties > > > system where userspace can ask for driver specific properties at > > > creation time. Also we need a way to allow to query the actual > > > framebuffer properties (ie one asked at creation might not work > > > and driver can adjust them so userspace have to requery properties > > > to know what have been done). > > > > What kind of properties did you have in mind? Why aren't the regular BO > > flags enough? Were you thinking of fence register allocation for tiled > > regions or something? > > We already discussed about on IRC and maybe mailing list :) but i believe > the outcome is that we don't touch BO. Yet i feel that we need to have > the framebuffer properties (tiling, compression, weird storage format) > in a driver dependant way somewhere along the framebuffer object and that > userspace should be able to query this properties to know (if userspace > clever enough) how to access the framebuffer or simply to properly > format blit command. > > > > > I also would like the BO argument to become optional ie if none > > > is supplied it's up to the driver to allocate a BO which fit > > > with the asked properties. Corollary frame buffer creation can > > > fail if supplied BO ain't big enough for the asked framebuffer > > > properties. > > > > Yeah, that should probably -EINVAL. > > > > > Finaly i am wondering if we should not provide some way to > > > update & get part of the framebuffer this could be especialy > > > usefull in case of dumb userspace which can't understand > > > framebuffer properties and if we ever have hw which can't have > > > linear framebuffer but need to store it in some strange > > > format (maybe embedded device already fall in this category). > > > > I guess you're thinking of the types of devices that use shadowfb now > > then upload the finished framebuffer into banked memory or whatever? > > Yes to that kind of device, and others that might appear in the future. > > > Cheers, > Jerome Glisse <gl...@fr...> > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Maarten M. <mad...@gm...> - 2008-02-28 22:26:22
|
On 2/28/08, Jesse Barnes <jb...@vi...> wrote: > On Thursday, February 28, 2008 11:33 am Dave Airlie wrote: > > the current API abstracts connectors from outputs, so in reality it > > is encoders with connector properties at the moment. > > > > you define a connector type and a connector id for each output and > > can gang them together.. > > > > so wrt to the kernel API, output == encoder, output != connector. the > > kernel API also contains no names just enums. > > > Maybe we should rename things internally to avoid confusion... > > > Jesse > > _______________________________________________ > xorg mailing list > xo...@li... > http://lists.freedesktop.org/mailman/listinfo/xorg > Is this new concept also the way it will be exposed to xorg and the user? Or will there be a wrapper in the ddx doing the "translation"? |
From: Dave A. <ai...@gm...> - 2008-02-28 23:18:42
|
On Fri, Feb 29, 2008 at 8:26 AM, Maarten Maathuis <mad...@gm...> wrote: > > On 2/28/08, Jesse Barnes <jb...@vi...> wrote: > > On Thursday, February 28, 2008 11:33 am Dave Airlie wrote: > > > the current API abstracts connectors from outputs, so in reality it > > > is encoders with connector properties at the moment. > > > > > > you define a connector type and a connector id for each output and > > > can gang them together.. > > > > > > so wrt to the kernel API, output == encoder, output != connector. the > > > kernel API also contains no names just enums. > > > > > > Maybe we should rename things internally to avoid confusion... > > > > > > Jesse > > > > > _______________________________________________ > > xorg mailing list > > xo...@li... > > http://lists.freedesktop.org/mailman/listinfo/xorg > > > > Is this new concept also the way it will be exposed to xorg and the user? > > Or will there be a wrapper in the ddx doing the "translation"? > Up to the DDX writer, for randr 1.2 you'll need to do some thunking if you have older names in config files etc.. Dave. |
From: Alex D. <ale...@gm...> - 2008-02-29 15:31:08
|
Sorry, mouse went wonky for a second there. On Fri, Feb 29, 2008 at 2:59 AM, Johannes Engel <jcn...@go...> wrote: > What did you want to say, Alex? I only got the quotes. ;) > > Greetings, Johannes > |