Skomentuj (0) 2007-11-14 11:23:40 Edytuj
And so it has happened. The idea of abandoning of software graphics generation using the SDL library in preference to OpenGL has turned from discussion on Wesnoth forums into reality, with recent creation of a seperate wesnoth-gl development branch. It doesn't, however, mean that the game will have the 3rd dimension added - the planned change is mostly a result of performance problems, which are the main drawback of using SDL or, to be exact, its usually not accelerated 2D backends. It may, of course, lead to Wesnoth being impossible to run old computers and these with hardly supported 3D acceleration hardware, but in most of the cases we expect a great improvement of UI smoothness.
Skomentuj (2) 2006-12-02 05:24:15 Edytuj
Kristoffer has put first patches into Russell's patch tracking system. I will wait with further development of that features until all of these patches get accepted or rejected.
Today I am working on CPUfreq support. Firstly, I had to enable sa1110 driver for Jornada 720 (in Kconfig). Of course it didn't work - the kernel froze on bootup. After some playing with the code I uncommented some dram timing recalculations in sa1110_target() in arch/arm/mach-sa1100/cpu-sa1110.c and it booted fine.
Then I learned that changing cpu frequency causes the system to freeze.
2.4.32 kernel with Michael Gernoth's jornada 720 patch did cpufreq fine, so I decided to make a comparison. I built 2.4.32 and tried to boot it. For some reason it didn't like the initrd. I tried to force it to use the initrd, but after some time I got bored of it and just did cpufreq calls in init/main.c ;).
I have narrowed down the freeze to some assembly code in arch/arm/mach-sa1100/cpu-sa1110.c. I've printk'ed all values used by this code in both kernels. They appeared different. I forced 2.6 values to 2.4 ones, and voila! 2.6 kernel has slown the cpu down to 59MHz.
Now I just need to determine what causes those changes in values (source data is identical for both kernels). Off to work ;).
Skomentuj (11) 2006-11-18 15:43:23 Edytuj
Anybody cares to do something ;)?
Skomentuj (0) 2006-11-12 14:01:32 Edytuj
Now s1d13xxxfb is the official framebuffer driver for Jornada 7xx devices :).
I got it all together and cleaned up a bit. It will be submitted to Russel King soon.
Stuff for testing purposes:
Skomentuj (0) 2006-11-12 13:05:32 Edytuj
I have decided to redesign things a bit. jornada720_mcu is now a bus driver, and devices utilizing MCU are now attached to this bus. That builds a bit more complex picture, but it's better managed and compatible with rest of the kernel. Every MCU device is ported to a bus model now.
Check this out:
root@jornada7xx:/sys/bus/jornada720_mcu_bus# ls devices/ drivers/ devices/: jornada720_apm jornada720_bl jornada720_kbd jornada720_lcd jornada720_ts drivers/: jornada720_bl jornada720_kbd jornada720_lcd jornada720_ts root@jornada7xx:/sys/bus/jornada720_mcu_bus#
There's a funny bug in linux console handling. TIOCLINUX ioctl for blanking the display requested on a tty never gets neither to framebuffer driver nor to backlight/lcd driver (they are together in framebuffer notifier chain for events, where blank requests land). It actually gets... ignored :). As soon as I am done with basic jornada stuff, I'll look into this.
For further power savings, I not only turn off the backlight as previous patches did, but I also turn off the LCD panel, and drive the epson gpu into standby mode with its output disabled.
Todo for nearest future: kick out our custom epson1256fb.c framebuffer driver, use s1d13xxxfb.c already present in kernel instead.
Skomentuj (0) 2006-11-11 22:03:35 Edytuj
I have just done a great thing :/.
I have declared an input device name as __initdata. Imagine the oopses when udevd tried to read device name from /sys some time after module loading ;).
I have a problem with the touchscreen driver, tslib doesn't recognize touch events. It used to with almost identical code... weird...
EDIT: HP documentation told me to trigger interrupt on falling edge, when in fact I should use a rising one. After fixing this touchscreen works like charm :).
As you can see, jornada 7xx support in kernel is progressing :).
Skomentuj (1) 2006-11-09 22:47:16 Edytuj
Yes, it works :).
I use standard kernel interfaces:
root@jornada7xx:~# find /sys/ -name '*jornada*' /sys/module/jornada720_bl /sys/module/jornada720_lcd /sys/module/jornada720_apm /sys/module/jornada720_kbd /sys/module/jornada720_mcu /sys/class/backlight/jornada720_bl /sys/class/lcd/jornada720_lcd root@jornada7xx:~# ls /sys/class/backlight/jornada720_bl actual_brightness brightness max_brightness power subsystem uevent root@jornada7xx:~# ls /sys/class/lcd/jornada720_lcd contrast max_contrast power subsystem uevent root@jornada7xx:~#
This means that any /sys compatible software will be able to control it. Opie for example :). Now time to clean up the touschreen driver and remove blanking code from the framebuffer driver. Off to work :)
Skomentuj (0) 2006-11-09 18:53:34 Edytuj