Re: [E-devel] Evas and the framebuffer
On Thu, 3 Aug 2006 00:59:28 +0200 Jorge Luis Zapata Muga [EMAIL PROTECTED] 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
Re: [E-devel] Evas and the framebuffer
You're right, ecore-fb has some problems and assumptions that need to be fixed. I'm very interested in doing this as well. For instance, to cope with rotated framebuffers, I had to add some glue code which you can find in the ecore part of my EFL++ binding: http://projects.linuxtogo.org/plugins/scmcvs/cvsweb.php/efl%2B% 2B/src/ecore/ecore.cpp?rev=1.1.1.1;content-type=text% 2Fplain;cvsroot=eflpp I'm also planning to submit more generic device handling functions in the future. The current stuff in ecore-fb is more or less tailored for one ipaq model. As part of the OpenEmbedded and Angstrom initiatives, we're working on making ecore-fb more useful on handhelds and phones. So in short, let's discuss :) -- Regards, Michael 'Mickey' Lauer | FreeLancer | http://www.Vanille-Media.de - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas and the framebuffer
Just to mildly change the subject here: Did you ever get that evas 'canvas' object, or subcanvas whatever, worked out? no, not at all. i just emulate it using a smart object. don't know if its useull beside my use case. Oh well.. :( Maybe it can be done a bit later. btw, i have a version of evas totally reorganized (headers, dirs, support to build engines outside evas) and some additions to support an object engine (usefull for things like evoak) as i noticed on a previous mail, evas will change in a while, does my changes will be usefull? if so i can contribute them. Engine funcs will change, and other internal aspects as well.. Also, the api's semantics will move to premul data/colors. Support for building engines outside evas?.. as in engine modules outside the evas cvs tree?.. ie. you have something like support for paths-to-engines? I guess that could be useful for independently developing engines for use with evas. What do you mean by an object engine? jose. - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas and the framebuffer
On 8/4/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Just to mildly change the subject here: Did you ever get that evas 'canvas' object, or subcanvas whatever, worked out? no, not at all. i just emulate it using a smart object. don't know if its useull beside my use case. Oh well.. :( Maybe it can be done a bit later. btw, i have a version of evas totally reorganized (headers, dirs, support to build engines outside evas) and some additions to support an object engine (usefull for things like evoak) as i noticed on a previous mail, evas will change in a while, does my changes will be usefull? if so i can contribute them. Engine funcs will change, and other internal aspects as well.. Also, the api's semantics will move to premul data/colors. Support for building engines outside evas?.. as in engine modules outside the evas cvs tree?.. ie. you have something like support for paths-to-engines? I guess that could be useful for independently developing engines for use with evas. Indeed, is usefull to develop engines without being part of evas main tree. What do you mean by an object engine? Its the abstraction needed to make evoak work, its a special type of engine. For example all the evas_object_* are redirected to the engine function so evoak (the engine) can send the request to the server. jose. - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas and the framebuffer
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. 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_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) 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 useless. 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Evas and the framebuffer
Hi all, I have several ideas/issues with the framebuffer and evas (also ecore_fb): I send this to know your opinions before i do any changes to the current code. best regards, turran So, you'd like to change the semantics of the evas_fb engine and ecore_fb initialization mechanisms.. or add extra initializing functions or ??? Just to mildly change the subject here: Did you ever get that evas 'canvas' object, or subcanvas whatever, worked out? jose. - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
