Firmware updates, dictionaries, fonts and third-party software for M92

[kodomo]

Another personal itch I scratched. Binaries and source patch attached, if anyone wants them (please read the README before using the scripts - as usual)

Basically, I wanted the option of using different scribble annotation colors.
Therefore, I modified pdf_tools and replaced them by a multi-color version.

Unfortunately, as I have no way of modifying the naboo_reader menu (neither naboo_reader nor gui_shell are open source), I had to do it in a hackish way:
The modified pdf_tools version interpretes stroke 'styles' for black strokes as color information (mapping them to thin lines in red/green/blue/black in the merged PDF).

The scripts allow to switch between the color_pdf_tools hack and Onyx's original version.

@Booxtor: If you could get them to provide me with a firmware version with additional gray-colors enabled (I saw in the source that they defined several levels, but use only black and white for some reason), I would try to integrate this in a better way.
As long as the options for different gray levels are shown in the menu (and the strokes correctly displayed on the original PDFs), I could modify pdf_tools in a way which allows to map the different gray levels to different colors (I tried to pick colors that are distinguishable even on the M92's grayscale screen)...

That being said: I'm actually puzzled they didn't enable different gray levels... I even have the impression that the original pdf_tools version would work with them - and I cannot imagine that they're able to implement different shapes, but not different gray levels (i.e. values in an existing, used variable)

Cheers.

P.S.: Note that the test script relies on the installed set of script_ui_primitives

[por]

-For me the issue with the power-management driver for the pen input is still there (pen refusing to continue writing after a pause in note-taking while the pen is being kept near the screen)

-Straight vertical and horizontal lines (scribbles) still don't get merged with the PDF.

-At least there is some good news: White scribbles are now merged as white allowing you to delete already merged notes

[PF4Mobile]

Originally Posted by kodomo

Another personal itch I scratched. Binaries and source patch attached, if anyone wants them (please read the README before using the scripts - as usual)

Basically, I wanted the option of using different scribble annotation colors.
Therefore, I modified pdf_tools and replaced them by a multi-color version.

Unfortunately, as I have no way of modifying the naboo_reader menu (neither naboo_reader nor gui_shell are open source), I had to do it in a hackish way:
The modified pdf_tools version interpretes stroke 'styles' for black strokes as color information (mapping them to thin lines in red/green/blue/black in the merged PDF).

The scripts allow to switch between the color_pdf_tools hack and Onyx's original version.

@Booxtor: If you could get them to provide me with a firmware version with additional gray-colors enabled (I saw in the source that they defined several levels, but use only black and white for some reason), I would try to integrate this in a better way.
As long as the options for different gray levels are shown in the menu (and the strokes correctly displayed on the original PDFs), I could modify pdf_tools in a way which allows to map the different gray levels to different colors (I tried to pick colors that are distinguishable even on the M92's grayscale screen)...

That being said: I'm actually puzzled they didn't enable different gray levels... I even have the impression that the original pdf_tools version would work with them - and I cannot imagine that they're able to implement different shapes, but not different gray levels (i.e. values in an existing, used variable)

Cheers.

P.S.: Note that the test script relies on the installed set of script_ui_primitives

Any chance that the pdf_tools can be modified to allow scribbling with straight lines only (i.e line vs free hand which we already have)?

[kodomo]

Originally Posted by PF4Mobile

Any chance that the pdf_tools can be modified to allow scribbling with straight lines only (i.e line vs free hand which we already have)?

pdf_tools is not responsible for scribbling itself - only for _merging_ of scribbles and annotations.

What you're calling for is essentially new scribble functionality. The crux with this is that even if you're able to implement it in the libraries, I currently see no way of making naboo_reader use such functionality (naboo_reader and gui_shell are closed source).

Sorry, but your chances (while not 0) seem pretty low, there

[PF4Mobile]

tks for clarifying that.
PF

[kodomo]

Originally Posted by Booxtor

Hi,
Could you please check this:
https://github.com/onyx-intl/public_kernel

It was recently published and I hope it is the stuff what you are missing.

If you think it is still incomplete please infom me.

Thank you for your tremendous work!!!

As you asked: Update on source repository issues...

CR3 still refuses to be built due to API problems:

Linking CXX executable ../../../../bin/cr3
CMakeFiles/cr3.dir/lcl_ui/line_edit.cpp.o: In function `ui::lcl_OnyxLineEdit::keyPressEvent(QKeyEvent*)':
line_edit.cpp:(.text+0x665): undefined reference to `ui::NumberDialog::NumberDialog(QWidget*, QString)'
collect2: ld returned 1 exit status

feed_reader is still missing the feed_action.h and feed_action.cpp files.

libcrypto (openssl) is still missing in the toolchain. (We know how to insert it - so it's more a nuisance than a real problem - and on a second thought, it could possibly be even an advantage, because it forces developers to use recent versions )

(that is: cp3 and feed_reader simply cannot be compiled - I have no clue as to whether the versions in the repository are up-to-date or not)


The kernel repository is missing a lot of crucial files
I'll attach a file list from a diff with the freescale kernel sources their kernel is based on.
Examples are:
initramfs_data.S initramfs_data.bz2.S initramfs_data.gz.S initramfs_data.lzma.S initramfs_data.lzo.S
(needed to build the initrd - these are the ones creating the first of a series of errors stopping kernel compilation )

I wonder why they removed them... some are indeed not needed (e.g., arch/alpha/*.S), but then again, neither are the remaining files in arch/alpha (which are included).
One could almost get the impression that they're making it explicitly hard to use the sources :-| .
Anyhow - the list of missing files is attached - they should simply add the full kernel source tree.



naboo_reader, gui_shell and system_manager are still closed source, but it seems very likely that these are not licensed under GPL anyway - so we can only kindly request access to these source (or a developer program)... I guess we'll eventually have to switch over to OpenBoox, since too many things cannot be properly done without the source.



W.r.t. the firmware: as I pointed out, I'd greatly appreciate the enabling of multiple gray levels for scribbling (I'd then update color_pdf_tools to interpret the gray levels as colors rather than hijacking the scribble styles). I deem this a very useful (and after all I see low effort on their behalf) modification.

One thing I'd be curious about: Does the naboo_reader rewrite also address the annoying space omission bug?

Cheers!

[Booxtor]

Originally Posted by kodomo

As you asked: Update on source repository issues...

CR3 still refuses to be built due to API problems:

Linking CXX executable ../../../../bin/cr3
CMakeFiles/cr3.dir/lcl_ui/line_edit.cpp.o: In function `ui::lcl_OnyxLineEdit::keyPressEvent(QKeyEvent*)':
line_edit.cpp:(.text+0x665): undefined reference to `ui::NumberDialog::NumberDialog(QWidget*, QString)'
collect2: ld returned 1 exit status

feed_reader is still missing the feed_action.h and feed_action.cpp files.

libcrypto (openssl) is still missing in the toolchain. (We know how to insert it - so it's more a nuisance than a real problem - and on a second thought, it could possibly be even an advantage, because it forces developers to use recent versions )

(that is: cp3 and feed_reader simply cannot be compiled - I have no clue as to whether the versions in the repository are up-to-date or not)


The kernel repository is missing a lot of crucial files
I'll attach a file list from a diff with the freescale kernel sources their kernel is based on.
Examples are:
initramfs_data.S initramfs_data.bz2.S initramfs_data.gz.S initramfs_data.lzma.S initramfs_data.lzo.S
(needed to build the initrd - these are the ones creating the first of a series of errors stopping kernel compilation )

I wonder why they removed them... some are indeed not needed (e.g., arch/alpha/*.S), but then again, neither are the remaining files in arch/alpha (which are included).
One could almost get the impression that they're making it explicitly hard to use the sources :-| .
Anyhow - the list of missing files is attached - they should simply add the full kernel source tree.



naboo_reader, gui_shell and system_manager are still closed source, but it seems very likely that these are not licensed under GPL anyway - so we can only kindly request access to these source (or a developer program)... I guess we'll eventually have to switch over to OpenBoox, since too many things cannot be properly done without the source.



W.r.t. the firmware: as I pointed out, I'd greatly appreciate the enabling of multiple gray levels for scribbling (I'd then update color_pdf_tools to interpret the gray levels as colors rather than hijacking the scribble styles). I deem this a very useful (and after all I see low effort on their behalf) modification.

One thing I'd be curious about: Does the naboo_reader rewrite also address the annoying space omission bug?

Cheers!

Thank you very much for the work. I have forwarded this information to Onyx.
Today we have signed NDA with Onyx and they promised to send us complete source codes of M92 software. It will make it easier for us to have more influence in developing of new features and bugfixes.

[kodomo]

Originally Posted by Booxtor

Today we have signed NDA with Onyx and they promised to send us complete source codes of M92 software. It will make it easier for us to have more influence in developing of new features and bugfixes.

This is interesting news... I guess it's unorthodox that a reseller is driven to the point of requesting source access... but then again, it's not the first unorthodox thing in Onyx's way of handling things :P

I'm not sure about the consequences to the developer community... do they outsource the management of a developer program to you?

Btw.: To look ahead what the next issues might be, I tried compiling the source using the files from the freescale kernel (they should nonetheless commit them to the repositories, as they might have changed them) - and found out that there seem to be more files missing (which I cannot find anywhere so far). E.g., in arch/arm/mach-mx5 :

make[1]: *** No rule to make target `arch/arm/mach-mx5/mx50_suspend.o', needed by `arch/arm/mach-mx5/built-in.o'.  Stop.
make: *** [arch/arm/mach-mx5] Error 2

Thx for forwarding the request!

Cheers!

[Dulin's Books]

Originally Posted by Booxtor

Thank you very much for the work. I have forwarded this information to Onyx.
Today we have signed NDA with Onyx and they promised to send us complete source codes of M92 software. It will make it easier for us to have more influence in developing of new features and bugfixes.

would you do that for the M90 please in case there are those that can fix that firmware? or at least get them to kick one more stable firmware out for us like the promised months and months ago...

[FrancoisL]

Originally Posted by kodomo

pdf_tools is not responsible for scribbling itself - only for _merging_ of scribbles and annotations.

What you're calling for is essentially new scribble functionality. The crux with this is that even if you're able to implement it in the libraries, I currently see no way of making naboo_reader use such functionality (naboo_reader and gui_shell are closed source).

Sorry, but your chances (while not 0) seem pretty low, there

A question that's somewhat but I want your opinion.

Given the sources and the toolchain posted by Onyx, is it possible to compile without too much effort, a QT application like GNU TeXmacs for the M92?

[FDD]

Originally Posted by kodomo

The kernel repository is missing a lot of crucial files
I'll attach a file list from a diff with the freescale kernel sources their kernel is based on.
Examples are:
initramfs_data.S initramfs_data.bz2.S initramfs_data.gz.S initramfs_data.lzma.S initramfs_data.lzo.S
(needed to build the initrd - these are the ones creating the first of a series of errors stopping kernel compilation )

Hello Komodo, I assume the initramfs isn't there because it contains the update password.
The initramfs can however be extracted trom a running kernel, so this "security through obscurity" is useless — and you can also change whatever you want with a simple script, so there is essentially no security at all. I don't really get what they are trying to do.

BTW I'm gonna be offline for a couple more weeks, then I'm going to give the kernel tree a try and report back.

Ciao!

Later edit: I gave a look around and since the update password is right there, but every assembler file (*.S) is missing from the tree, this probably means there is some bit written in assembler they refuse to release, obviously violating the GPL.

[kodomo]

Originally Posted by FrancoisL

A question that's somewhat but I want your opinion.

Given the sources and the toolchain posted by Onyx, is it possible to compile without too much effort, a QT application like GNU TeXmacs for the M92?

I'm not the GUI guy, to be honest ... but in principle it should be fairly easy to do... there are three things I see you could have to fix:
- getting the build environment to use the toolchain
- screen refreshing
- adding the on-screen-keyboard (or usb hostmode with hid support ) so you can input text

I think tuxor has a better overview than I w.r.t. Qt ... even better: Koudjis (he's developing OpenBoox for the A60)

But all in all, the SDK is relatively painless to use (see development Wiki), and porting not a major issue... the Qt in the SDK seems to be a Qt4 with some extensions.

Cheers.

P.S.: If you have devel/porting questions - feel free to join the devel-thread and ask questions there

[kodomo]

Originally Posted by FDD

Hello Komodo, I assume the initramfs isn't there because it contains the update password.
The initramfs can however be extracted trom a running kernel, so this "security through obscurity" is useless — and you can also change whatever you want with a simple script, so there is essentially no security at all. I don't really get what they are trying to do.

BTW I'm gonna be offline for a couple more weeks, then I'm going to give the kernel tree a try and report back.

Ciao!

It is not the initramfs missing... just some source files with assembler code (which are even part of the std. vanilla kernels )
Moreover, they have some directories that seem to allow building initrd images and boot environment as well (didn't check that out, yet).

However: very welcome to help checking things out - the more the merrier

Cheers.

[FinancialWar]

can someone teach me how to update the firmware?

Do unzip the downloaded file first or not?

[Booxtor]

Originally Posted by FinancialWar

can someone teach me how to update the firmware?

Do unzip the downloaded file first or not?

it is actually also described in the very first post

You dont have to unzip anything.

Firmware Updating:

1. Copy the file to a sd card and put it into your device
2. Just for case if your battery is not charged properly connect the reader to the wall charger (or USB Port of your PC)
3. switch off the reader
4. hold the ok /joystick button pressed and switch on the device.
5. Wait approx. 10 minutes till the device restarts

That's it