Hi,
> So I guess I have to add a dest_clip bool parameter when moving them.
> /me looks for a good place. drm_fb_helpers.c I think.
https://git.kraxel.org/cgit/linux/log/?h=drm-rewrite-cirrus updated.
v2 series will follow later today or tomorrow.
cheers,
Gerd
Den 04.04.2019 12.27, skrev Gerd Hoffmann:
> Hi,
>
>>> tinydrm_xrgb_to_*
>>>
>>> imo these could be put into some drm_format_helpers.c to be shared.
>>
>> I agree, my long term goal is to get rid of tinydrm.ko. Just haven't got
>> there yet.
>>
>> Gerd, if you end up using some of those fu
Hi,
> > tinydrm_xrgb_to_*
> >
> > imo these could be put into some drm_format_helpers.c to be shared.
>
> I agree, my long term goal is to get rid of tinydrm.ko. Just haven't got
> there yet.
>
> Gerd, if you end up using some of those functions, feel free to move
> just those you need an
Den 04.04.2019 10.52, skrev Daniel Vetter:
> On Thu, Apr 4, 2019 at 10:30 AM Gerd Hoffmann wrote:
>>
>> Hi,
>>
Speaking of wayland: Seems at least gnome-shell insists on using XR24.
>>>
>>> Yeah XR24 is pretty much mandatory. Noralf added a few helpers to
>>> convert XR24 to other format
On Thu, Apr 4, 2019 at 10:30 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > > Speaking of wayland: Seems at least gnome-shell insists on using XR24.
> >
> > Yeah XR24 is pretty much mandatory. Noralf added a few helpers to
> > convert XR24 to other formats, for display not supporting anything
> > else.
Hi,
> > Speaking of wayland: Seems at least gnome-shell insists on using XR24.
>
> Yeah XR24 is pretty much mandatory. Noralf added a few helpers to
> convert XR24 to other formats, for display not supporting anything
> else. Because userspace.
Have a pointer to these helpers? grepping aroun
Hi,
> > Speaking of wayland: Seems at least gnome-shell insists on using XR24.
>
> Yeah XR24 is pretty much mandatory. Noralf added a few helpers to
> convert XR24 to other formats, for display not supporting anything
> else. Because userspace.
Ah, right, that is an option too. Given we blit
On Thu, Apr 4, 2019 at 7:51 AM Gerd Hoffmann wrote:
>
> On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote:
> > On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
> > >
> > > Time to kill some bad sample code people are copying from ;)
> > >
> > > This is a complete rewrite of the cirr
On Thu, Apr 04, 2019 at 12:58:09PM +1000, David Airlie wrote:
> On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
> >
> > Time to kill some bad sample code people are copying from ;)
> >
> > This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> > function is pretty much the o
On Wed, Apr 3, 2019 at 7:58 PM David Airlie wrote:
> On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
> >
> > Time to kill some bad sample code people are copying from ;)
> >
> > This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> > function is pretty much the only funct
On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann wrote:
>
> Time to kill some bad sample code people are copying from ;)
>
> This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> function is pretty much the only function which is carried over largely
> unmodified. Everything else
On Wed, 2019-04-03 at 16:15 +0100, Daniel Stone wrote:
> There's already a list of supported formats for each DRM plane, which
> you can get via drmModeGetPlane (being careful to enable universal
> planes so you can discover the primary plane). The same information is
> present in the 'IN_FORMATS'
On Wed, 3 Apr 2019 at 16:12, Adam Jackson wrote:
> On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> > - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
> >that too by default. There was a module parameter which enables 24/32
> >bpp support and disables highe
On Wed, 2019-04-03 at 09:23 +0200, Gerd Hoffmann wrote:
> - Only DRM_FORMAT_RGB565 (depth 16) is supported. The old driver does
>that too by default. There was a module parameter which enables 24/32
>bpp support and disables higher resolutions (due to cirrus hardware
>constrains).
Hi,
> > So I can just remove cirrus_fb_dirty() and hook up
> > drm_atomic_helper_dirtyfb() instead. Easy ;)
>
> You can even use drm_gem_fb_create_with_dirty() instead of
> drm_gem_fb_create_with_funcs().
Ah, cool. /me happily continues removing code lines.
thanks,
Gerd
PS: incremental f
Den 03.04.2019 10.53, skrev Gerd Hoffmann:
>>> +struct cirrus_device {
>>> + struct drm_device *dev;
>>
>> Why not embed drm_device? It's the latest rage :-)
>
> Sure, can do that.
>
>>> +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
>>> +
> > +struct cirrus_device {
> > + struct drm_device *dev;
>
> Why not embed drm_device? It's the latest rage :-)
Sure, can do that.
> > +void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> > + struct drm_plane_state *old_state)
> > +{
> > +
On Wed, Apr 3, 2019 at 9:23 AM Gerd Hoffmann wrote:
>
> Time to kill some bad sample code people are copying from ;)
>
> This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
> function is pretty much the only function which is carried over largely
> unmodified. Everything else
Time to kill some bad sample code people are copying from ;)
This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
function is pretty much the only function which is carried over largely
unmodified. Everything else is upside down.
It is a single monster patch. But given that i
19 matches
Mail list logo
