Boox (M92) developer community?

[kodomo]

Hi folks... if anyone else was thinking that a console application might come in handy for developing: I stumbled across something I lack the time (and Qt coding proficiency ) to make work, but which might help there:
qtermwidget ( http://qtermwidget.sourceforge.net/ ) is a Qt4 terminal widget (as in QtWidget )

[kodomo]

Btw.: What are you folks currently (part-time ) hacking on?

Do you think it'd make sense to have a wiki page where everyone posts what he's currently up to (to see whether there's overlap?)

FDD: I'd be interested to know whether you're still working on the kernel config. On the longer run, I'm interested in having a look on the host-mode issue (when I have more time ), to see whether one could attach a bt-dongle and a bt-keyboard, e.g....

Currently, I
- probably will hack a small demon to address the SD-write issue next (it is sad that the closed system_manager bars us from real clean 3rd party solutions -_-')
- am taking a look at the pdf_tools to see whether I can convince it to produce multiple colors. If I'm not mistaken, it really should be trivial for Onyx to add more gray levels to the scribble menu (they already have more gray levels in the enum structure - and are saving effective gray levels... so how difficult can it be?) - in which case the pdf_tools could be modified to map gray levels to colors.

Btw.: I think we should nag again w.r.t. the kernel - 1.5 months should be sufficient to add some sources to the git repository

[tuxor]

I'm currently trying to set up a useable qemu arm build environment with debian squeeze armel. Still looking for an easy solution to exchange files between the host and the qemu guest. And I'm trying to build qt-4.7.3 to have a qt environment in the correct version... My long term target is PySide or PyQt, whichever is easier to build.

[rkomar]

Originally Posted by tuxor

I'm currently trying to set up a useable qemu arm build environment with debian squeeze armel. Still looking for an easy solution to exchange files between the host and the qemu guest. And I'm trying to build qt-4.7.3 to have a qt environment in the correct version... My long term target is PySide or PyQt, whichever is easier to build.

Have you tried using scp for transferring files? Inside the guest, the host can be reached at 10.0.2.2 in the default setup.

[kodomo]

Originally Posted by rkomar

Have you tried using scp for transferring files? Inside the guest, the host can be reached at 10.0.2.2 in the default setup.

Moreover: NFS should be an option... and if I'm not mistaken, then qemu VMs may be integrated into VirtualBox (which afair also supports some additional mechanisms to interface with host FS) [Pointer: http://liquidat.wordpress.com/2007/1...tualbox-image/ ]

[tuxor]

thanks for your replies! unfortunately, virtualbox does not support emulating ARM systems. in general, there is a very limited range of vm software with arm support. I don't even know, whether vmware or any other commercial software supports arm...

[kodomo]

Originally Posted by kodomo

- probably will hack a small demon to address the SD-write issue next (it is sad that the closed system_manager bars us from real clean 3rd party solutions -_-')

Hrm - basically got things working, now... but adding the scripts to startup is troublesome: both adding it to appstart.sh and rc.config resulted in boot freezes which had to be solved by reflashing... did anyone successfully added stuff to the boot sequence?

Another thing I stumbled upon has me a little worried... looking at watchdog.sh, I see a check for free space on /root:

        remain_cap=`df | grep mmcblk0p2 | awk '{print $4}'`
        if [ $remain_cap -ge 1024 ]; then
        ...

...and an action to take, if internal memory's full:

root_files="web_browser.db notes_template notes"
    for i in $root_files
    do  
    ...
        rm -rf /root/$i

...They really intend to delete the user's notes to free up space!?!

Update: ok... so root is not 'the' internal memory... but then again, I think that /root is not the safe place to put the notes

[Mono]

Originally Posted by kodomo

Btw.: On the longer run, I'm interested in having a look on the host-mode issue (when I have more time ), to see whether one could attach a bt-dongle and a bt-keyboard, e.g....

Try to wait for final 1.7 firmware. In current firmware there already might be a USB Host ability, but not enabled and integrated to interface... In About Info there is a reference to SW that allows USB Host mode.

Possibility to attach BT keyboard (and GPS) would be really fine.

[kodomo]

Originally Posted by Mono

Try to wait for final 1.7 firmware. In current firmware there already might be a USB Host ability, but not enabled and integrated to interface... In About Info there is a reference to SW that allows USB Host mode.

Possibility to attach BT keyboard (and GPS) would be really fine.

That script is already there (and I guess it's used when the device is connected to a PC and exporting its file system), but the kernel modules for other modes and usb devices are missing.

I'd be very much surprised if they added it officially, as it's way off the official use of the device and will just have users whine about missing support for USB dongle xyz .

FDD: can you share the config file, please?

[Koudijs]

Originally Posted by kodomo

Hrm - basically got things working, now... but adding the scripts to startup is troublesome: both adding it to appstart.sh and rc.config resulted in boot freezes which had to be solved by reflashing... did anyone successfully added stuff to the boot sequence?

I made modifications to rc.conf to start some daemons at powerup (A60). Have you checked that all scripts are marked as 'executable' in their permissions? Is the script reachable at boot time? (path variable set, sd card mounted, etc)

[mSSM]

Originally Posted by kodomo

Hrm - basically got things working, now... but adding the scripts to startup is troublesome: both adding it to appstart.sh and rc.config resulted in boot freezes which had to be solved by reflashing... did anyone successfully added stuff to the boot sequence?

Another thing I stumbled upon has me a little worried... looking at watchdog.sh, I see a check for free space on /root:

        remain_cap=`df | grep mmcblk0p2 | awk '{print $4}'`
        if [ $remain_cap -ge 1024 ]; then
        ...

...and an action to take, if internal memory's full:

root_files="web_browser.db notes_template notes"
    for i in $root_files
    do  
    ...
        rm -rf /root/$i

...They really intend to delete the user's notes to free up space!?!

Update: ok... so root is not 'the' internal memory... but then again, I think that /root is not the safe place to put the notes

Apart from the fact that they don't seem to have a clue how to use the Linux file system - the coding style is horrible.

a) Why would you 'grep' the output of 'df' when you can just pass it the path to the file system directly?
b) Why would you _still_ use backticks for command substitution? That is just terrible, terrible style! Somebody tell them to use $() instead.
c) How can you not quote your variables?
d) Why would you loop over, essentially, a string, if you could (should!) use an array?? That is simply retarded.
e) Why would you use an old test [ if there is the simpler [[ ? (Okay, this one is not a biggy...)

Except for e), all of the above are really bad mistakes. Is somebody honestly earning money writing that crap?

[kodomo]

Originally Posted by mSSM

Apart from the fact that they don't seem to have a clue how to use the Linux file system - the coding style is horrible.

a) Why would you 'grep' the output of 'df' when you can just pass it the path to the file system directly?

You possibly would, if you were unsure whether the FS is mounted (or where) and you don't want to get the info about the wrong FS (but they obviously don't consider this in this place, or they would have at least quoted their variable, and written an if-statement :P)

Originally Posted by mSSM

b) Why would you _still_ use backticks for command substitution? That is just terrible, terrible style! Somebody tell them to use $() instead.

*cough* *lol* folks who started scripting a _long_ time ago still do.
I have to admit that I'm amongst those who never bothered finding out the subtle difference between the two... backticks work, as long as you're not trying to use them inside a backtick environment... so why not use them?
...same for [

Originally Posted by mSSM

c) How can you not quote your variables?

Yes - evil, indeed, though not exactly the point I wanted to make *g*

Cheers!

[mSSM]

Originally Posted by kodomo

You possibly would, if you were unsure whether the FS is mounted (or where) and you don't want to get the info about the wrong FS (but they obviously don't consider this in this place, or they would have at least quoted their variable, and written an if-statement :P)

You don't need to use an if-statement. 'df' returns a zero exit status if everything worked out correctly, and a non-zero exit-status if no FS was mounted.

And if you don't know where the FS is mounted, then what's the point of all this?

[kodomo]

Originally Posted by Koudijs

I made modifications to rc.conf to start some daemons at powerup (A60). Have you checked that all scripts are marked as 'executable' in their permissions? Is the script reachable at boot time? (path variable set, sd card mounted, etc)

modifications to rc.conf:
(added it to end of cfg_services)
- script is made executable
- /etc/rc.d/init.d should be available when rcS is called
- rcS calls script with explicit path - should be ok
(script relies on another helper script placed in /usr/local/bin)
- 2nd script is executable
- /usr/local/bin is part of the root partition - should be ok
- otherwise, the 1st script just uses busybox functionality (without an explicit path - but then again, so does, e.g., filesystems)

Nonetheless, the device freezes while booting...

(the appstart.sh attempt indeed probably was a dumb mistake in late-night-stupor - not making appstart.sh executable again after modification *cough* - but rc.config looks like the cleaner solution)

[Koudijs]

Originally Posted by kodomo

modifications to rc.conf:
(added it to end of cfg_services)
- script is made executable
- /etc/rc.d/init.d should be available when rcS is called
- rcS calls script with explicit path - should be ok
(script relies on another helper script placed in /usr/local/bin)
- 2nd script is executable
- /usr/local/bin is part of the root partition - should be ok
- otherwise, the 1st script just uses busybox functionality (without an explicit path - but then again, so does, e.g., filesystems)

Nonetheless, the device freezes while booting...

(the appstart.sh attempt indeed probably was a dumb mistake in late-night-stupor - not making appstart.sh executable again after modification *cough* - but rc.config looks like the cleaner solution)

Some more questions, I hope they get you closer to the solution:
- Is the second script called by the first via an absolute path or is /usr/local/bin in $PATH?
- Perform the scripts one time actions or do they start a process in the background?
- What happens if you only echo some text in script 1 and 2? (redirect the output to e.g. /tmp/boot.txt) Does it boot? What's in the output file?