Re: Proposed widget type: image

Hallo all!

Am 26.01.2014 11:09, Markus Dolze wrote:
> On 22.01.2014 23:28, Scott Meharg wrote:
>> If interested, attached is a patch that adds a new widget type for
>> displaying images files on graphic LCDs that use the glcd driver.
>>
>> Only PNG image files are supported.  glcd_render_image attempts to
>> transform the image to 24 bits/pixel and transparency is removed by
>> compositing against a white background.  Any pixel not white will be
>> turned on on the LCD.
>>
>> If need be I will work on updating the documentation.
>>
>> Would this be considered a new version of the API?
>>
> Hi Scott,
>
> First of all - I am still vary and have not decided about it. Some more
> feedback from others would be great.
>
> Some thoughts:
>
> The client needs to know which files are available on the server. I
> imagine a media center software (e.g. XBMC) that displays some radio or
> TV station logos via LCDd running on the same machine. This sounds like
> a nice extension to LCDproc, but is limited to graphical drivers. But
> using serdisplib a number of graphical LCD can be used.
Some time ago I had the same idea.
I'm pretty satisfied with the textmode-Display on my HTPC. I really 
don't want fully graphic one, but a channel-logo would be a real cool 
feature.

The MDM166a and the popular Imon displays (at least some types) are 
graphical displays too.
So there are a lot of users who would benefit from it.

> In the past we denied code changes that output arbitrary files on the
> display for security reasons. At some time it was suggested to read a
> text file during start-up (when LCDd still runs as root).
>
> In your scenario (during normal operation) LCDd does not run as root
> anymore. If permissions are set correctly LCDd will not be able access
> files it shouldn't be able to read. And you are not reading text, but
> PNG files only.
I don`t think it is a good idea to do ti that way, there are to many 
restrictions.
The LCDd has to have access to the Image files of the client, which is 
not necessarily the case.
On one machine, relative pathnames and file permissions might be an issue.
Using this feature via LAN, would be quiet a hassle. One will need a 
local copy of all images on the server or a NFS or Samba share.

I would prefer a simple 1bpp protocol to transfer the data from the 
client to the server instead.
At the intended use with channel-logos, status "icons", etc. the amount 
of data will still be manageable, I think.

A typical channel-logo of 4 x 2 characters will have about 500 pixels 
[2x4 x (8+1)x(5+1)]. This would be equivalent to about 65 characters and 
the logo wont change often. I'm pretty sure the LCDd will handle that 
easily, even if we have some additional overhead.

Transfering only the pixels shown has several convenient side effects 
for us too.
The code for reading an scaling the pictures is moved to the clients. So 
we don't have to deal with different picture-formats, scaling types,... 
and the Client has the full control what will be displayed.

Regards
Stefan