Launching X11 Environment From Sd Card
- Thread starter dftruf
- Start date
Small update:
Booting a newer debian requires a kernel >= 2.6.26 (udevd won't start otherwise) so I'll be going with lenny for now.
Ultimatively I need to integrate the wiz-drivers into a newer kernel. AFAIK even the newest firmware still uses 2.6.24.
It was a bit tricky to setup the network correctly between the device an my host but now I could update the debian package list with the one from emdebian grip.
Now I'll try to setup X on the framebuffer...
Booting a newer debian requires a kernel >= 2.6.26 (udevd won't start otherwise) so I'll be going with lenny for now.
Ultimatively I need to integrate the wiz-drivers into a newer kernel. AFAIK even the newest firmware still uses 2.6.24.
It was a bit tricky to setup the network correctly between the device an my host but now I could update the debian package list with the one from emdebian grip.
Now I'll try to setup X on the framebuffer...
Success:
Here is a crappy photo of the Wiz running X11 on the Framebuffer. WM is Matchbox which seems to be very good for this job. Also as promised 'xclock'.
http://www.informatik.uni-bremen.de/~hiben/wiz_matchbox.jpg
Sorry for the poor quality. The batteries in my real camera are dead and my Android Phone is quite stupid with the flash...
The touchscreen is already working but needs calibration.
It seems that rotation is supported by the driver... will check that out now...
*edit*
Rotation works, also for touchscreen. Calibration is really needed because I can only reach the lower quarter of the screen right now...
It also seems that there is MESA Software OpenGL on this thing now... Need to check that out too... ;-)
Here is a crappy photo of the Wiz running X11 on the Framebuffer. WM is Matchbox which seems to be very good for this job. Also as promised 'xclock'.
http://www.informatik.uni-bremen.de/~hiben/wiz_matchbox.jpg
Sorry for the poor quality. The batteries in my real camera are dead and my Android Phone is quite stupid with the flash...
The touchscreen is already working but needs calibration.
It seems that rotation is supported by the driver... will check that out now...
*edit*
Rotation works, also for touchscreen. Calibration is really needed because I can only reach the lower quarter of the screen right now...
It also seems that there is MESA Software OpenGL on this thing now... Need to check that out too... ;-)
Darkknight512
Active Member
Looks great man, what can you do so far?
StarG
Member
hiben said:
hiben said:Success:
Here is a crappy photo of the Wiz running X11 on the Framebuffer. WM is Matchbox which seems to be very good for this job. Also as promised 'xclock'.
http://www.informatik.uni-bremen.de/~hiben/wiz_matchbox.jpg
Sorry for the poor quality. The batteries in my real camera are dead and my Android Phone is quite stupid with the flash...
The touchscreen is already working but needs calibration.
It seems that rotation is supported by the driver... will check that out now...
*edit*
Rotation works, also for touchscreen. Calibration is really needed because I can only reach the lower quarter of the screen right now...
It also seems that there is MESA Software OpenGL on this thing now... Need to check that out too... ;-)
GREAT, its x11 running and looking good
What do you plan next?dfTruF said:
If i remember right that specific WM tries to maximise application area so it defaults to adjust the window size to its fitting. May need a few setting tweaks to have large applications or even a switch to Flux. Server should have no problem to enable a virtual display area i assume.
Last edited by a moderator:
I'll get back to some of the posts later; now just a quick status report.
I'm currently working on the touchscreen calibration which turns out to be complicated because lenny has a buggy version of the tslib driver...
When I wanted to patch it I could not install the needed dev-packages right now... so I have some mixed lenny/grip system right now that still does not what I want... (yes, I compile on the Wiz...)
Maybe I'll start over with pure lenny or patch a newer kernel and take a look at the newer ones...
One think about this 2x2 desktop idea. There might be a problem with the touchscreen since it reports absolute coordinates.
Has anyone used a touchscreen on a virtual screen before ? Are there solutions ?
A workaround would be to move a large window in the small screen and use no virtual screenspace...
I'm currently working on the touchscreen calibration which turns out to be complicated because lenny has a buggy version of the tslib driver...
When I wanted to patch it I could not install the needed dev-packages right now... so I have some mixed lenny/grip system right now that still does not what I want... (yes, I compile on the Wiz...)
Maybe I'll start over with pure lenny or patch a newer kernel and take a look at the newer ones...
One think about this 2x2 desktop idea. There might be a problem with the touchscreen since it reports absolute coordinates.
Has anyone used a touchscreen on a virtual screen before ? Are there solutions ?
A workaround would be to move a large window in the small screen and use no virtual screenspace...
hiben said:
What does it mean - '2x2 desktop idea'?
I thought it should be simple to switching between virtual screen parts (through wiz button), for example:
virtual 640x480:
## | ## <== one '##' part has 320x240 pixels physically displayed on wiz
## | ## <== I push L + down (for example) for switching to this part
So touch screen delivers coordinates from one specific part (e.g. from left down corner)?
Last edited by a moderator:
Darkknight512 said:
I can start X11 and programs. But I have no input and the touchscreen driver has bugs. So effectively I can make the cursor jump around...
Seriously: It's a proof-of-concept at the moment but I'm confident that I can add many more things. First thing to add is an on-screen-keyboard...
StarG said:hiben said:hiben said:
GREAT, its x11 running and looking good
[...]
If i remember right that specific WM tries to maximise application area so it defaults to adjust the window size to its fitting. May need a few setting tweaks to have large applications or even a switch to Flux. Server should have no problem to enable a virtual display area i assume.
There might be a problem with the virtual area: The driver must support it.
I know that the hardware can do it but maybe I need to modify the driver in the kernel (no big deal... just need to test carefully...)
dfTruF said:
Yes, scrolling through the parts would not be the problem but:
The touchscreen is not mapped to the physical but to the *virtual* screen; so if you are in the first quarter of the touch-screen you are in your first quadrant in the virtual screen (fully) and so on (that means, first quarter of the TS maps cursor to whole physical display). This would be very wierd because the cursor is next to useless then...
Maybe a solution would be to use the touchscreen like a touchpad (so moving the cursor by swiping...) or hacking some evil driver that does the job... maybe the latter would be better...
I've never seen a touchscreen on a virtual screen. Maybe there are solutions...
In other news:
I'm currently modifying the u-boot bootloader to be able to boot from SD when i press the L key while booting (just like the R key for firmware update).
Detecting the key works and now comes some parsing stuff (bootargs on SD and so on). This will make modding the Wiz a lot easier...
*edit*
My bootloader is now working... really convenient to just press a key instead of hacking the same things again and again into the u-boot prompt.
Of course this allows anyone to totally trash their system when using a destructive script...
I will of course make all these changes available; just give me some time for cleanup...
Last edited by a moderator:
hiben said:
At least cursor can be moved through directions buttons on wiz (if touchscreen is too complicated to implement).
Good solution for virtual keyboard will be the most important part of user's input. I think that this should be extremely customizable by the user - decision which button activates virtual keyboard, which buttons (or combinations of buttons) map to instant keyboard key or combo of keys. This should be configurable in some file.
Next very important tools are (in my opinion): C/C++ compiler & standard tools, SDL (with zlib, png, freetype, fmod) & OpenGL libs & headers, html browser with Java & Flash player.
*edit*
My bootloader is now working... really convenient to just press a key instead of hacking the same things again and again into the u-boot prompt.
Of course this allows anyone to totally trash their system when using a destructive script...
As long as instructions in the script doesn't change anything on NAND (in firmware linux) then it should be safe.
Last edited by a moderator:
Just keeping this alive:
I have not given up yet - I just rebuilt my Wiz 'Breakout' Board using more patience and planning. Turns out my USB host is not fried - my unshielded connection was just too long... Now I'm able to connect mice and keyboard for quick testing again...
Also I did a complete reinstall and this time it's a pure Lenny system. Took some time to install but now I have all the tools needed to patch buggy drivers...
I'll implement the keys as a Joystick device (GPH/MES did create some weird kernel modules for this device...) and so the generic joystick input driver could be used... I'll keep you informed on the progress there.
OpenGL is a issue on itself... MES (the board producer) only ships binary drivers. Software OpenGL works and I get fantastic 28FPS out of GLXGears... ;-) . Maybe I can still use the binary from the Wiz but I'll see that later.
Java gets interesting. Sun does not produce Java for ARM so it's either OpenJDK or GCJ... let's see how that turns out.
Flash... a.k.a. the nightmare... no ARM support for that but planned for some years (only one implementation for a Nokia device is known (licenced)). Maybe one of the open source players like gnash will do but they are not very compatible...
Maybe I can get Wine to work on this thing... don't know if it's even possible on ARM...
Off-Topic: GPH/FunGP is selling a game called Frozen Bubble that looks very much like the GPLed thing with the same name (which is itself a clone of a comercial game). GPH just can't respect the IP of others can they ?
*edit*
Just correcting myself: AFAIK the Wiz also has a licensed Flash library. Maybe that one can be recycled too.
I have not given up yet - I just rebuilt my Wiz 'Breakout' Board using more patience and planning. Turns out my USB host is not fried - my unshielded connection was just too long... Now I'm able to connect mice and keyboard for quick testing again...
Also I did a complete reinstall and this time it's a pure Lenny system. Took some time to install but now I have all the tools needed to patch buggy drivers...
dfTruF said:
I'll implement the keys as a Joystick device (GPH/MES did create some weird kernel modules for this device...) and so the generic joystick input driver could be used... I'll keep you informed on the progress there.
OpenGL is a issue on itself... MES (the board producer) only ships binary drivers. Software OpenGL works and I get fantastic 28FPS out of GLXGears... ;-) . Maybe I can still use the binary from the Wiz but I'll see that later.
Java gets interesting. Sun does not produce Java for ARM so it's either OpenJDK or GCJ... let's see how that turns out.
Flash... a.k.a. the nightmare... no ARM support for that but planned for some years (only one implementation for a Nokia device is known (licenced)). Maybe one of the open source players like gnash will do but they are not very compatible...
Maybe I can get Wine to work on this thing... don't know if it's even possible on ARM...
Off-Topic: GPH/FunGP is selling a game called Frozen Bubble that looks very much like the GPLed thing with the same name (which is itself a clone of a comercial game). GPH just can't respect the IP of others can they ?
*edit*
Just correcting myself: AFAIK the Wiz also has a licensed Flash library. Maybe that one can be recycled too.
Last edited by a moderator:
hiben said:Just keeping this alive:
I have not given up yet - I just rebuilt my Wiz 'Breakout' Board using more patience and planning. Turns out my USB host is not fried - my unshielded connection was just too long... Now I'm able to connect mice and keyboard for quick testing again...
Good to hear you again.
Unfortunately I cannot use my wiz now comfortably because my directional d-pad doesn't work, and I had to took apart wiz:
http://www.gp32x.de/board/index.php?/topic/58820-how-to-repair-directions-buttons/
I'm thinking how to fix it.
Maybe you have some experience on restoring membrane under d-pad on wiz?
My vision of this linux with X on wiz is that user can compile small C/C++ programs directly on wiz, which use standard libs, OpenGL, SDL, playing (not compiling) Java & Flash applications, and use his own windows sizes (for bigger virtual screen), customizable mapping (buttons to keys) combinations. This is all (maybe too difficult to implement).
They must have because official firmware uses flash player.
Last edited by a moderator:
So I finally patched the touchscreen driver and it works. It's not very precise so I attached a mouse also... maybe I can figure out how to filter it better...
Behold the horror:
http://www.informatik.uni-bremen.de/~hiben/wiz_browser.jpg
(Iceweasel in 320x240)
Iceweasel takes very much memory from the swap partition and is really slow... I'll need a smaller browser but could not find Dillo in Lenny at first glance...
Maybe using links2 is not such a bad idea after all...
Sorry, no idea. I've seen your other thread. Post a picture; maybe someone has an idea then...
Java and Flash apps will bring this device down really fast... there is just so little memory...
I'm thinking of adding a fast USB memory storage for swapping (and maybe also storage). The SD driver seems to be the thing that slows down everything for some reason... Maybe an ultra slim stick could fit in the casing of the Wiz...
Behold the horror:
http://www.informatik.uni-bremen.de/~hiben/wiz_browser.jpg
(Iceweasel in 320x240)
Iceweasel takes very much memory from the swap partition and is really slow... I'll need a smaller browser but could not find Dillo in Lenny at first glance...
Maybe using links2 is not such a bad idea after all...
dfTruF said:
Sorry, no idea. I've seen your other thread. Post a picture; maybe someone has an idea then...
It's a nice vision but the Wiz is really slow and compiling takes ages... but maybe it's something for the patient... I'm a Gentoo user after all ;-)dfTruF said:
Java and Flash apps will bring this device down really fast... there is just so little memory...
I'm thinking of adding a fast USB memory storage for swapping (and maybe also storage). The SD driver seems to be the thing that slows down everything for some reason... Maybe an ultra slim stick could fit in the casing of the Wiz...
Last edited by a moderator:
hiben said:
Do you use faster NAND as a swap partition?
So my vision is shattered now.
I thought that NAND as a swap space will be quite fast, not as RAM but still "playable".
But at least, terminal applications should work fine?
Last edited by a moderator:
dfTruF said:
I did not benchmark the NAND yet (but will do in a few minutes) but the real problem is that NAND is not suitable for swapping. The technology behind NAND only allows a limited count of writes to a block before it becomes unusable (~10000 - 100000 writes if I recall correctly) which is not a problem if you just store files. Also NAND needs software based wear leveling (unlike SD cards and usb storage sticks which do it in hardware) which is in case of the Wiz done by ubifs. So if we swap to NAND we wear it down very fast and also put a stress on the CPU.
Now you might think: wait a minute, that guy is swapping to the SD card ?! - and you are right. The SD card will die if I use this setup over a prolonged time but it is very easy to replace the card instead of replacing the NAND... I already killed one SD card in a similar setup used in a netbook so this is not just theoretical...
On the other hand I think that resource aware software will work fine under X. A colleague showed me the uzbl web interface tools[1] today. I hope this will be a solution for the small screen and the low memory...
And of course terminal things should also be fast. I'll try the small font soon and see if I can activate console rotation for the standard console.
[1] http://www.uzbl.org
Last edited by a moderator:
hiben said:
This mess with swap really puts down the potential of this project on wiz. Wearing out NAND or SD through often writing is unacceptable. So I would use it for very small applications which don't use swap at all.
Last edited by a moderator:
dfTruF said:
Yeah, the swapping is a downer... the 42M of memory are enough for (simple/old) games but multimedia has higher demands...
I benchmarked the NAND and the SD with hdparm (hdparm -t).
The NAND does ~3.5MB/s while the SD does ~2MB/s (linear read times). Writing will be worse but I did not want to test that yet. I'll also need to benchmark the SD on my Desktop since I think the Wiz is using a 1-bit interface... the SD could be much faster in theory. Maybe using a hub + usb storage is still faster then on the Wiz.
Also the console rotation is working and when I use the 4x6 font I get 80x30 characters. Thats pretty good for terminal applications. Screenshots will follow tomorrow since my phone really can't handle the OLED brightness. BTW: sound (OSS) is working out of the box.
Last edited by a moderator:
hiben said:
I think that we should forget about swap on wiz.
4x6 font is too small (in my opinion), long reading in this size can be very exhausting.
I prefer bigger font (6x10) with scrolling or switching the virtual screen.
But in a good system, user should decide how big the font should be.
Are 42M of memory enough for compiling small program in C/C++(up to about 10M) on wiz, which use SDL and x-term?
Last edited by a moderator:
dfTruF said:
Linux only swaps when it has to so there is no penalty in having some swap ready in any case. I'll try some usb storage soon and see if it is faster.
I'm not sure if I actually want to read texts on that device - well, maybe playing a text adventure while on train would be nice
- but font size is a matter of taste and eyesight. At least this part is easy to configure...The virtual screen thing is still on my mind but I need to do some recherce before I start experimenting...
What exactly do you mean by 'small program up to about 10M' ? 10M source is quite a lot, 10M binary file also...
The memory requirement depends more on the structure - a complex, single object file can take quite some memory while being compiled (especially for C++) - but 100 simple ones are no big deal...
When it comes to compiler options I would guess that piping should not be used to speed up the process as the pipes need memory. On the other hand, compiling takes longer then... (and I did not check how much impact piping has)
I'm not sure if at the final linking stage all of the binary code has to be in memory... this could be the real limit (the linking, not the compilation)
Last edited by a moderator:
hiben said:
I thought that you have implemented virtual screen already. Web browser which you have showed must use virtual screen. It was 640x480?
But you are going to attach compiler and standard libraries to final system?
Last edited by a moderator:
