This repository has been archived by the owner. It is now read-only.

[hammerhead] directfb mode issue #49

Closed
MartijnBraam opened this Issue Sep 11, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@MartijnBraam
Member

MartijnBraam commented Sep 11, 2017

I've got this working on the hammerhead with the info on the debugging wiki page.
The current mode I use, which is not the same as fbset -s:

mode "1080x1920-1"
        # D: 1.243 MHz, H: 1.142 kHz, V: 0.593 Hz
        geometry 1080 1920 1080 1920 16
        timings 804667 2 4 2 2 2 2
        accel false
        rgba 5/11,6/5,5/0,0/0
endmode

The hammerhead has still the not-refreshing issue. Apparently this is not really a bug but the way this driver does double buffering, sadly directfb doesn't support this double buffer method yet.

Thanks to zhuowei on IRC we now know that in the android recovery they flip the buffer like this: https://github.com/LineageOS/android_bootable_recovery/blob/6a0693fcce0fea8fd41252ba176aa8e3de33b953/minui/graphics_fbdev.cpp#L77

which is basically the same thing as doing cat mode > mode.

3 possible options for making this work:

  1. Add a workaround flag to osk-sdl that does that ioctl on the framebuffer device in the render loop
  2. Add this refreshing method to directfb somewhere
  3. Write a DRM driver for hammerhead
@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Sep 11, 2017

Member

Does the patch mentioned here work on the 0.48 release of osk-sdl (without the workaround I submitted being applied to osk) ?

Member

craftyguy commented Sep 11, 2017

Does the patch mentioned here work on the 0.48 release of osk-sdl (without the workaround I submitted being applied to osk) ?

@drebrez

This comment has been minimized.

Show comment
Hide comment
@drebrez

drebrez Mar 26, 2018

Member

@MartijnBraam @craftyguy do you think this can be closed? it should be solved with the msm_fb_refresher or do you actually want to add the same ioctl calls directly in osk-sdl?

Member

drebrez commented Mar 26, 2018

@MartijnBraam @craftyguy do you think this can be closed? it should be solved with the msm_fb_refresher or do you actually want to add the same ioctl calls directly in osk-sdl?

@craftyguy

This comment has been minimized.

Show comment
Hide comment
@craftyguy

craftyguy Mar 26, 2018

Member

I'm OK with closing it if it's no longer a problem because msm_fb_refresher can be used instream. I don't have a device that needs msm_fb_refresher, so I was not able to personally reproduce this original issue. Also, I didn't really want to do the same ioctl from within osk-sdl.. that was a hack/experiment.

Member

craftyguy commented Mar 26, 2018

I'm OK with closing it if it's no longer a problem because msm_fb_refresher can be used instream. I don't have a device that needs msm_fb_refresher, so I was not able to personally reproduce this original issue. Also, I didn't really want to do the same ioctl from within osk-sdl.. that was a hack/experiment.

@MartijnBraam

This comment has been minimized.

Show comment
Hide comment
@MartijnBraam

MartijnBraam Mar 26, 2018

Member

This is fixed with the msm refresher right now (and maybe completely avoided whene mainline runs :D)

Member

MartijnBraam commented Mar 26, 2018

This is fixed with the msm refresher right now (and maybe completely avoided whene mainline runs :D)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.