On 3/27/07, Lars Munch <[EMAIL PROTECTED]> wrote: > Hi turran > > On Tue, Mar 27, 2007 at 02:39:12PM +0200, Jorge Luis Zapata Muga wrote: > > Hi all, i have coded several things to ecore_fb, but before doing a > > commit i prefer your opinion or whishlist =) > > > > 1. Modules for input devices. Instead of having the input devices > > exclusive (linux_input or ps2/keyboard/tslib combo), ive made an > > abstraction to support input "modules" (for now they are just > > statically linked - its a similar approach to what evas had on the > > beginning with engines). For now we don't need real modules because > > the input modules is the only module type we have. > > > > 2. More Input Devices: A while ago i coded the linux_input (event > > devices) support and replace the input devices that were on ecore_fb > > (tslib, keyboard, ps2) to support multiple devices (i.e two mice, > > three keyboards, whatever). I've re-enabled the replaced ones, > > following the module approach. > > > > 3. Support for keyboard layouts, in ecore_fb the keyboard layout was > > hard coded to english layout (ascii values only), with this code we > > can use different layouts (spanish, french, or your own), it was coded > > following the keymaps(5) idea. Ive also made a parser for keymaps (the > > files you have under /usr/share/keymaps/) which will export a c source > > file for now, i want to also export an eet file, but it wont be done > > until my eet patch gets in. btw, where's a good place to put this > > application? under /src/bin of ecore? on tests dir in cvs? > > > > 4. Support for not allocating a virtual terminal (in case there's no > > console attached to the fb) and code to specify which fb device to > > use. > > > > I still have one doubt with all of this, ecore_fb will have a lot of > > flexibility (input devices, fb to use, vt to allocate, etc) so it will > > fit very well for embedded/specific platforms. But we need a way to > > set up the configuration for libs/apps working with ecore_fb like > > ecore_evas or etk, does it makes sense to also create some kind of > > configuration file with a fallback in case none exists? if so, eet, > > plain text? > > IMHO a plain text config is preferable since the configuration will be > platform specific and not library/application specific and therefore > must be editable without some special tool. >
Good point =) > I have one wish: I have been working on support for absolute coordinates > for my touchscreen and have the basics working but without calibration. > We need some way of calibrating a specific input device as this is not > possible with current framework. Yes, im aware of that, im also porting the old calibration code to a common framework. Calibrating a tslib device *in* ecore_fb is pointless, tslib already has its own way of doing it (using a linear filter and special files), but it is indeed usefull for an evdev , so at the end we will do something similar to what tslib's linear filter code does. > > I am looking forward to seeing the code. > > -- Lars Munch > > > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
