If it is not too device specific, I can put it on a branch and we can
haggle through the details before merging it to master.
I think your original proposal for nx_updatedisplay() would be okay
if it were renamed and took three arguments like:
int nx_synch(NXWINDOW hwnd, int cmd, unsigned l
On 12/17/2019 10:10 AM, Gregory Nutt wrote:
So, I think the path here is that I'll tidy up what I've done and
then I'll submit it for comment and kickabout, and see where we go
from there.
If it is not too device specific, I can put it on a branch and we can
haggle through the details befo
So, I think the path here is that I'll tidy up what I've done and then
I'll submit it for comment and kickabout, and see where we go from there.
If it is not too device specific, I can put it on a branch and we can
haggle through the details before merging it to master.
Linux uses Xorg for graphics. So if this feature is supported in
Linux, then I think it would be through Xorg? The NX server is the
tiny, moral equivalent of the XServer.
This is interesting:
https://hackaday.com/2018/08/14/run-a-linux-terminal-on-cheap-e-ink-displays/
The interface is w
On 12/17/2019 9:03 AM, Dave Marples wrote:
How are other operating systems / graphics libraries handling this?
From what I've seen they mostly don't...you end up with a parallel
graphics subsystem built on top of an SPI. We can do better than that,
given that very little needs to be extende
How are other operating systems / graphics libraries handling this?
From what I've seen they mostly don't...you end up with a parallel
graphics subsystem built on top of an SPI. We can do better than that,
given that very little needs to be extended.
Regards
DAVE
It means that some practical
details of the implementation of the display technology are 'leaking' up
into the graphics abstraction, but I don't really see a way to avoid it.
Only the application knows when it's permissible to take an extended
time to perform an update.
How are other operating
On 12/17/19, Gregory Nutt wrote:
> Thanks. I understand better now.
>
> This is very specific to this hardware.I don't think this should
> involve the graphics system in such a device-specific way since this is
> a hardware interfacing issue that has nothing to with graphics other
> than a gr
For easy hacks, I would suggest a minimal, trivial device driver that
just supports the the FBIO_UPDATE command (and any other command
unique to the hardware). This driver would have to lie in the
board-specific logic or else have an SPI interface passed to it during
initialization. Or may
Thanks. I understand better now.
This is very specific to this hardware. I don't think this should
involve the graphics system in such a device-specific way since this is
a hardware interfacing issue that has nothing to with graphics other
than a graphics device is involved. There are eas
On Tue, Dec 17, 2019 at 8:44 AM Dave Marples wrote:
> It means that some practical
> details of the implementation of the display technology are 'leaking' up
> into the graphics abstraction, but I don't really see a way to avoid it.
> Only the application knows when it's permissible to take an ex
Hi Greg,
Thanks for the replies. Comments embedded;
What is the interface to the ePaper device? Is it through a serial
interface? Or a framebuffer interface?
The interface is over SPI. It 'looks like' a normal lcd supported by
lcd_dev_s. The particular one I have is write-only, but read/wri
Hmm...going further, the only way I see to deal with this at the nxgl
layer above the lcd structure itself is to add a nx_redraw with
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but
that makes the nxgl layer device-aware...I don't see how it can't be
really, these thing
I don't really see any way to avoid this. Greg, any suggestions for a
better approach?
I would needed to understand how you are forming these displays, where
the display resides (in application memory), and how you are interfacing
from the "display" to hardware. I really don't have a clue
... I want to go the other way - when the application has decided that
a new display is 'stable', it requests for it to be put on the screen.
I don't understand what that means. Where is this new display?
I need to understand more before I could comment.
I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update
an ePaper display.
What is the interface to the ePaper device? Is it through a serial
interface? Or a
Hmm...going further, the only way I see to deal with this at the nxgl
layer above the lcd structure itself is to add a nx_redraw with
corresponding NX_EVENT_REDRAWING/NXEVENT_REDRAWN event callbacks, but
that makes the nxgl layer device-aware...I don't see how it can't be
really, these things a
Hi Alan,
I'm no expert on this stuff either but as I understand things the
nx_callback/redraw, is for when nx requests that the client redraws a
portion of the screen (See 2.3.4.1 of the NX Graphics Subsystem manual).
I want to go the other way - when the application has decided that a new
di
Hi Dave,
On 12/17/19, Dave Marples wrote:
> Folks,
>
> I've implemented an ePaper driver under nxgl, but as some of you are
> probably aware there needs to be an explicit redraw request to update an
> ePaper display.
>
Other guy already used ePaper with NX Graphic libs, if I'm not wrong
it was P
Folks,
I've implemented an ePaper driver under nxgl, but as some of you are
probably aware there needs to be an explicit redraw request to update an
ePaper display.
I'm not quite sure how to do that under nxgl as normally it would be
driven automatically. It also takes a fair bit of time (~1
20 matches
Mail list logo
