[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[E-devel] Evas and the framebuffer
I have several ideas/issues with the framebuffer and evas (also ecore_fb):
1. The fb engine currently has some kind of library made by raster
which in my opinion overlaps in some way with the ecore_fb approach.
The engine_info has a vt and a fb parameter both integers, i guess it
was used to make evas allocate itself the terminal where the fb should
be (map the console to the fb), that code is currently commented so i
guess the vt parameter is no longer used.
2. when you do an evas_output_size_set the fb lib on the engine tries
to first find a suitable mode on fb.modes (in /etc) if its found it
setups the fb to that size and then draws on it, if it isnt found it
just draws on a part of the fb memory of that size. I think (as in
other engines) that the initialization and configuration should be
done outside the engine itself (by the app). One way to accomplish
this is to just pass the file descriptor of the framebuffer device, so
evas itself just needs to check if the device of that fd is actually a
fb (using a ioctl) and then use it as it does now. (no resize)
3. Mixing the above and ecore_fb makes some inconsistency, first
ecore_fb_init parameter isnt used at all (it always read on fb0), then
if you use ecore_evas_fb_new and want your app to be the size of the
current fb you have to call:
ecore_evas_fb_new(..., w, h); // note here ecore_fb_init is also
called, it wont do anything as the lib is already initialized but is
kind of inconsitent
to keep evas quit and dont change the resolution. So changing
responsabilities on ecore_fb and evas fb engine would be a good idea.
If you want your app to be of size WxH then the actual approach is
valid if you find the correct mode. So my idea will be to do something
like this (for the second use case):
or using ecore_evas
ecore_evas_fb_new(W,H) // same applies for the first case (same size
as current fb size)
4. ecore_fb doesnt allows you to not map a virtual terminal to the fb
device (very usefull for testing and dont screw your terminal) and
also doesnt allows you to use several fb's like having fb0 and fb1 and
then (with ecore_evas_fb for example) have two evases there.
5. i currently code the linux input handling on ecore_fb replacing the
old ps2 (still isnt fully operative: no absolute axis) but when you
launch an ecore_fb it will always allocate a vt and in my opinion both
are too tight, as raster said ecore_fb is dependant to the input
system and i agree but i think this doesnt applies on the other side
(the input isnt dependant to the display) So if the init function
could have more parameters to define its functionality would be good.
6. evas fb always maps the fb memory but for fb drivers where you cant
actually map the memory and just write/read to the fd, evas is
I send this to know your opinions before i do any changes to the current code.
ps: as always if i not explain myself correctly, sorry for my english :)