Re: Proposed widget type: image
Stefan Herdler <[email protected]> Wed, 12 Mar 2014 03:14:52 +0100
| Newsgroups | gmane.comp.sysutils.lcdproc |
|---|---|
| Message-ID | <[email protected]> |
Hallo! Custom-characters has been already requested some time ago. In that context my thoughts has been as follows: Am 06.03.2014 07:26, Markus Dolze wrote: > Hi > > Short story: > > I thought about using custom characters. But that did not work well. > > > Long story: > > First my idea was to create a new widget. Call it 'cchar' for now. It > will have a position (X/Y in characters) and its 'content' is the pixel > data. > > Upon rendering, LCDd first use set_char() to set the pixel data, then > use chr() to display the character. > > For standard text displays (HD44780) usually 5x8 pixels are needed (8 > bytes a 5 bits). So we could simply shift binary data by one or two bits > and are save. > > Clients are told the character dimensions in response to 'hello', so > they can split their image into 'cchar'. > > Some questions remain, e.g.: How does the LCDd assign the address in > CGRAM dynamically? And how is it released again for some other cchar? I would let the user decide how to assign the custom-characters. The Server only provides a number of custom-characters by request. My suggestion is to map these custom-characters directly into the beginning of ascii code (0x01 ... 0x09) this region is currently not used. Or to overwrite characters which have to be defined by the client while setting up every custom-character. As result the user/client can fill custom-characters with data and then use them like normal characters. But we still have the conflict with the build-in functions using custom-characters like bars, etc.. > Then I turned to the graphics driver and the above turned out to not > work any longer: > > * First it does not handle custom characters (it has no set_char). It > would need to implement some 'CGRAM' . So far the set_char function is only used internally with es very limited set of custom characters. If the Display can keep all needed custom characters internally there is no need for a set_char function in the driver. I don't see anything against adding a set_char if we need it. - except someone has o do it ;-). regards Stefan