You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That works, although I had to invert the image (or rather stop inverting it, by using "1;R" instead of "1;IR").
The following patch works for me:
diff --git a/ev3dev/core.py b/ev3dev/core.py
index 0dd29ca..72d0f41 100644
--- a/ev3dev/core.py+++ b/ev3dev/core.py@@ -3317,7 +3317,8 @@ class Screen(FbMem):
Nothing will be drawn on the screen until this function is called.
"""
if self.var_info.bits_per_pixel == 1:
- self.mmap[:] = self._img.tobytes("raw", "1;IR")+ b = self._img.tobytes("raw", "1;R")+ self.mmap[:len(b)] = b
elif self.var_info.bits_per_pixel == 16:
self.mmap[:] = self._img_to_rgb565_bytes()
else:
I am bit surprised by the result though. tobytes("raw", "1;R") should give us raw 1-bit-per-pixel image. Why assigning the result to a 2-bit-per-pixel framebuffer works?
The fbdev device has two modes of operation, 1bpp and 2bpp. Be default, it still operates in 1bpp mode. The memory allocated has to be big enough for both modes, so the 1bpp mode only uses 1/2 of the allocated memory.
Activity
ddemidov commentedon Oct 28, 2017
@dlech, were there any changes in framebuffer on stretch? For reference, here is what we currently do:
ev3dev-lang-python/ev3dev/core.py
Lines 3093 to 3234 in 02fa602
dlech commentedon Oct 28, 2017
There is now 2bpp support in the driver, so
fix_info.smem_lenis probably twice as big as it was previously.Could you change
to
?
ddemidov commentedon Oct 28, 2017
That works, although I had to invert the image (or rather stop inverting it, by using "1;R" instead of "1;IR").
The following patch works for me:
I am bit surprised by the result though.
tobytes("raw", "1;R")should give us raw 1-bit-per-pixel image. Why assigning the result to a 2-bit-per-pixel framebuffer works?dlech commentedon Oct 28, 2017
The fbdev device has two modes of operation, 1bpp and 2bpp. Be default, it still operates in 1bpp mode. The memory allocated has to be big enough for both modes, so the 1bpp mode only uses 1/2 of the allocated memory.
ddemidov commentedon Oct 28, 2017
Ok, that makes sense. I'll create PRs for
stretch-stableanddevelopthen.dlech commentedon Oct 28, 2017
I'm wondering about the inversion though. I don't recall switching from
FB_VISUAL_MONO10toFB_VISUAL_MONO01but maybe I did.ddemidov commentedon Oct 28, 2017
Do you need more info from me on this? The EV3 is next to me right now.
dlech commentedon Oct 28, 2017
The driver still says
FB_VISUAL_MONO10, so I would expect that the inversion is still needed.https://github.com/ev3dev/lego-linux-drivers/blob/ev3dev-stretch/linux/fbdev/st7586fb.c#L483
ddemidov commentedon Oct 28, 2017
Well, without the inversion
s.clear()gives me black screen, ands.draw.rectangle((10,10,168,118))gives me a white-on-black rectangle.Fix Display class on stretch.
dlech commentedon Oct 28, 2017
ev3dev-lang-python/ev3dev/display.py
Line 257 in 8e57eea
says clear should fill with white, not black
ddemidov commentedon Oct 28, 2017
I believe that is because we had to do inversion.
Fix Screen class on stretch.
Fix Screen class on stretch. (#425)
Fix Display class on stretch. (#424)
ddemidov commentedon Oct 29, 2017
Fixed by #424 (
develop, aka v2) and #425 (stretch-stable, aka v1). Also pushed the updated packages for the stretch-stable version.