[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas and the framebuffer

On Thu, 3 Aug 2006 00:59:28 +0200 "Jorge Luis Zapata Muga"
<jorgeluis.zapata@gmail.com> babbled:

> Hi all,
> 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.

yeah - it was very early code and i never really paid a lot of attention to it.
it was intended so yu can specify the vt to find the fb of - or possibly
allocate a vt - but i found that was better done in ecore as it tied into
hooking to the subsystem (gaining access to the vt, locking it down etc.) so
only the fb device # is really important/used.

it could do with cleaning for sure.

> 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)

why not do it as it is currently? it allows for either using the fb in whatever
mode it is now, or setting the mode (resolution anyway) and in theory it
could/should set depth too. but it doesn't atm. i think evas can handle that as
it opens the fb dev itself. any reason for your way that would be better?

> 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:

OR you just tell ecore_evas to go fullscreen - it's done for you. :) so no need
to fiddle with the fb device yourself to get its resolution.

> ecore_fb_init
> ecore_fb_size_get(w,h)
> 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):
> ecore_fb_init
> ecore_fb_size_set(W,H)
> evas_output_size_set(W,H)

i think that ecore_evas should entirely be the front-end there, and internally
set the resolution if needed and depth etc.

> or using ecore_evas
> ecore_evas_fb_new(W,H) // same applies for the first case (same size
> as current fb size)

yes - this makes sense.

> 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.

yup - this needs work :) if we ever had/have fb based apps worth working on..
then this would become important... do you have plans for such apps? :)

> 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.

well ecore_evas_fb_new() does accept a display name - this is currently just
NULL by default and then ecore_evas_fb will need to try do the most sensible
thing (really it should allocate a new vt and pretty much do whatever x does -
but it doesn't. this does need fixing). if you provide informaton we can parse
it and define it (eg define what vt to run on - or alloc a new one, what
devices to use etc. etc.)

> 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
> useless.

yup. :) though there are not many of those... :) i would consider them "out of
scope" personally :) but.. if you want to spend the time on it.... :)

> I send this to know your opinions before i do any changes to the current code.
> best regards,
> ps: as always if i not explain myself correctly, sorry for my english :)
> turran
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
Tokyo, Japan (東京 日本)