From: Bernard L. <le...@bo...> - 2003-04-02 09:29:53
|
Hi Florin, The major problem with the frame buffer for the iPod is that it doesn't provide linear addressable display memory. As I understand it, most of these libraries will mmap() the frame buffer and then write directly to display memory. Unfortunately on the iPod that won't work becuase the display memory is in the LCD and therefore not directly accessible. The framebuffer keeps an in-memory copy of the memory and then writes any updates to the LCD. It would be possible to have an update thread that continually re-writes the data to the LCD so that the mmap() type approach would work. I'm not sure how cpu intesive this would be. Alternatively with a package like Microwindows you can write a Microwindows driver that forms an interface between its drawing routines and the display hardware. Regarding an actual interface - the directory structure sounds like a good place to start. That should be doable using the current display driver using something like ncurses. Any takers? cheers, bern. On Mon, 2003-03-31 at 12:30, Florin Boariu wrote: > From: Florin Boariu <fl...@bn...> > To: Bernard Leach <le...@bo...> > Subject: Re: [Ipodlinux-devel] hello > Date: 31 Mar 2003 11:31:19 +0200 > > > To answer your second question first, work is on-going on the project. > > I'm still trying to get hardware support into the kernel for all the > > iPod devices. I'm getting there but its slow going. Currently I am > > working on the power management aspects to see what I can do about > > limiting battery usage. > > great to hear -- i browsed through the ml archive yesterday and realized > myself that there was a lot going on :-) > > > Other than the kernel work the biggist missing part is a GUI. I had > > thought to use Microwindows (since its already part of the uClinux build > > tree). I custom display driver needs to be written so to allow > > Microwindows to use the iPod display. The driver could be based on the > > current framebuffer so it shouldn't be too hard. > > whay about DirectFB? it seems to be a pretty good fbdev graphics library > with hardware support for a lot of things (which of course won't be of > any use on the ipod) and software fallbacks for all they have :-) > > i had some thoughts on the topic "GUI": maybe a simple but efficient way > would be to implement some sort of directory browser with ... aehm "file > handles" for different types of files. MP3/OGGs could be direcly > inserted into a play queue (that's what i miss on my current ipod -- the > possibility to dynamically create playlists / play queues), iTunes or > XMMS playlists could be played directly, several text files in plain > ASCII (or even XML) format could be treated appropriately (GNUpod > playlists could be played, several address and/or diary formats could be > displayed etc). > > this allows simple building of menu systems by just creating directories :-) > > i had some thoughts on text imput, maybe based on some (intelligent?) > dictionary files and auto-completion. a typical while typing would look > like: > > o find an edit field > o start with letter 'a' as first letter of the word. the system > auto-completes the most appropriate word starting with 'a' > o if you don't want the word to start with 'a', just scroll to the > desired letter as first letter of the word. the system constantly > auto-completes the possible words to type (starting with 'b', 'c', > whatever. > o advance to the second letter (for example by pressing the > "fast-forward" key. scroll that one to the desired shape > (with system constantly auto-completing). > o when you're happy, press some enter button (for example "play"). > > this certainly won't be as good as a keyboard, but maybe it could be > somewhat usable if only the dictionary files are good enough > (menu-sensitive dictionary files: look up in name data bases while > typing addresses, look up in PATH while typing in a shell, look up in > playlists while typing songs etc...) > > what do you think? > > regards, > florin. > |