XFCE app.menu and panel auto-hide / NanoEmacs / xev

[bsp]

Hi all,

 just got my Pandora yesterday (nice device! 50Hz vsync
 Amiga/C64 emulators rock for sure!)

 I noticed that when the XFCE panel is set to "auto-hide",
 the Pandora key does not show the app. menu anymore.

 So I wrote a replacement script that fixes this issue:
 


#
# Show or hide XFCE application/popup menu when Pandora key is pressed.
#
# (drop-in replacement for "/usr/pandora/scripts/op_xfcemenu.sh" which
# does not work when the panel auto-hide feature is enabled)
#

MENU_SY=`xwininfo -name xfce4-menu-plugin|grep Height|awk '{print $2}'`

if [ 1 -eq $MENU_SY ]; then
xfce4-popup-menu
else
WINID=`xwininfo -name xfce4-menu-plugin|grep 'Window id:'|awk '{print $4}'`
xdotool keydown --window $WINID Escape
fi

besides more interesting things which are still work-in-progress, I also

ported NanoEmacs (ne) and xev today (see attachment).

Maybe someone else has a use for these.

Greetings,

Bastian

p.s.: can someone tell me the shortcuts for PageUp/Down ?

 

[levi]

Page up/down are the Y and X buttons.

Curiously, the xfce panel on my device isn't configured to auto hide.  But then I'm not on the very latest firmware yet.

We already have <a href="http://repo.openpandora.org/?page=detail&app=emacs-x11">emacs ported</a> and packaged up into the PND system the Pandora uses.  But that's a couple of years old, so I guess your port may be newer, and we don't have xev yet (unless you opkg install it, presumably).

Very nice work, and good to have another dev on board!

Edit: And that emacs is full fat.  Nice to have a slimmer version with familiar commands (at least to those who aren't vi-heads like me).  A PND'ed version would probably get a wider audience though.

 

[bsp]

Hey Levi,

 for some reason the Y/X buttons do not work in the "Terminal" (just prints a "~" char).

 xev says they are mapped to "Prior" and "Next", will have to take a look at that tomorrow.

 The XFCE panel is not configured for auto-hide, that's right. I just loved me some more

 screen estate that's why I enabled it (I also wrote another small script that puts the

 terminal into a fake fullscreen mode -- appmenu does not work w/ the real fullscreen mode).

 I am aware of the emacs (24, no X) port (thanks for that, whoever did that!).

 The reason why I ported NanoEmacs is that I am not much of a VI guy and NE is a lot

 smaller (~260K vs. ~1.5MB) so I'll probably delete VI to gain some space

 A PND for that would be overkill, I guess.

 

[Mr_Loon]

Hi bsp & welcome.

I auto-hide the Panel so your script is much appreciated here

 

[peelie]

great script, very useful ,thanks

 

[bsp]

hi Mr_loon and peelie! thx for the welcome and good to hear that you find it useful.

maybe the script should be integrated into the next SuperZaxxon

release (can't see why not)

Btw, in the meantime I was able to figure out my page up/down scroll problem:

turns out that shift+Y/X scrolls the terminal "view", while Y/X alone send

the proper escape sequences (e.g. interpreted by text editors). simple as that

EDIT:

 now this is just a detail but I like my shells fullscreen with no window decorations

 at all. Once I disabled the scroll/menu/toolbars and borders using the

 terminal preferences, and also turned on panel auto-hiding, I noticed that the

 terminal window does not fill the entire screen (besides the 1 pixel panel area).

 If you put the following script


#
# Resize "Terminal" window to fake fullscreen
#
# (in actual fullscreen mode, the Pandora key does not show
# the application menu anymore)
#
# (also make sure to disable the menu/tool/scroll bars and
# borders in the Terminal preferences)
#
#

WINID=`xwininfo -name Terminal|grep 'Window id:'|awk '{print $4}'`
xdotool windowsize $WINID 800 479


into ~/scripts/terminal_ffs.sh (mkdir that folder)

and add


alias ffs=". ~/scripts/terminal_ffs.sh"

 to your ~/.bashrc

you can then type "ffs" to fix the window size to fit the screen.

..just a detail but hey

p.s.: ..or just exec the script automatically in .bashrc..

 

[levi]

 for some reason the Y/X buttons do not work in the "Terminal" (just prints a "~" char).

 xev says they are mapped to "Prior" and "Next", will have to take a look at that tomorrow.

 The XFCE panel is not configured for auto-hide, that's right. I just loved me some more

 screen estate that's why I enabled it (I also wrote another small script that puts the

 terminal into a fake fullscreen mode -- appmenu does not work w/ the real fullscreen mode).

 I am aware of the emacs (24, no X) port (thanks for that, whoever did that!).

 The reason why I ported NanoEmacs is that I am not much of a VI guy and NE is a lot

 smaller (~260K vs. ~1.5MB) so I'll probably delete VI to gain some space

 A PND for that would be overkill, I guess.

In a terminal on my laptop, pgdn does produce a tilde (while pgup produces nothing). I guess that's because the normal arrows operate the history, not scrolling. I tried out a document in evince, and X and Y appeared to be doing page down and up there just as they do on my laptop (i.e. screen up and down, unlike in the Adobe document viewer).

The X-included PND of emacs was produced in 2011 so was probably based on Emacs 23.  And it's a chunky 18MB.

I guess PNDing it up might be a bit excessive.  If done properly it would save NAND flash wear (which most Pandora users tend to be very wary of), but I guess most people wanting it would be developers who were quite capable of running the OS from an SD card where they can fill it up and wear it out as much as they like.  Seems vi on the Pandora is actually linked to an instance of vim which is a hefty 1.5MB you could save from your Pandora OS

I guess your explanation helps show why I still have my XFCE bar not autohiding, as I normally do set it to auto-hide - I must've tried it in the past.  I'll give your script a go now, ta!

 

[levi]

Hmm, if I full-screen the terminal (F11 - or Fn-O on the Pandora), and right click to disable the menu bar and go into the preferences and set the scroll bar to disabled, I seem to be able to get the terminal completely filling the screen as if the Pandora supported a text mode display.  Even with the xfce bar not autohiding, F11 overrides it.

 

[bsp]

yep, but the terminal fullscreen mode prevents the Pandora key from working


(maybe it's still working but the terminal overlays the menu !?)


EDIT: my bad - the menu key works in FS after all so forget about the FFS script!


the only advantage of FFS is that pressing the Pandora key shows the panel


(if you want to take a quick look at the clock and battery status)


as for flash wear-out: that's only relevant for write access, that should


be avoided as much as possible (e.g. don't place tmp files in NAND)


like probably most of you I have two SDCards -- one permanently mounted


(for custom kernel, boot.txt, PNDs, tmpfiles, ..) and the other one for


ROMs/MP3s/videos/samples and what not.


p.s: last but not least, since I just have the Pandora since yesterday: so far I am quite pleased with it.


The display is far better than I expected (viewing angles + the 50Hz feature is really appreciated!), the desktop feels responsive, short boot time, great battery life and the controls (dpad/nubs) have a quality feel to them.


I still have to figure out what's causing the occasional sound lag/stutter in the Amiga/C64 emulators (haven't tried any others so far).


This seems to occur approximately every ~10sec, which is not much of a problem when you are focusing on a game but becomes a bit irritating when running a demo / just listening to the music (MP3 playback in Audacious/DeaDBeeF is fine, though!)


however, this is definitely a keeper. great job, Pandora team!


from a dev point of view I also have to mention that Ivanovic's toolchain installation and compilation of the official GIT repositories (kernel, SDL, ..) worked out of the box. nice!


TI's dsplink once again was disappointing since it took quite some effort to build/install and in the end PROC_attach() caused nothing but kernel crashes (used the OMAP3530 config).


I am currently working on a replacement for that (wish me luck!)


(in TI's honour -- the HW is great and they have PDF documentation for virtually everything!)

 

[freamon]

Hi,

Glad to see you're enjoying your new device.

If you want to maximise your screen space, you might want to give Openbox a try. This also lets you write rules for how each application will launch, so you can write one for the terminal so that it always launches 'fullscreen' (i.e. maximized, with no decoration). Also, the Pandora key will still bring up the menu with a fullscreen terminal running.

 

[bsp]

yes, Openbox is sth. I'd like to try somewhen in the future.

Right now I'm concentrating on the "official" firmware / kernel.

Actually I've been through a real coding spree today (erm..yesterday..3:15 A.M. here in Hamburg)

But..Good news everyone!

On my quest to get rid of DspLink I wrote a DSPImage (COFF2) loader and some DSP setup code today (knee deep in TI manuals..)

Just got it working (and it's properly coded, almost MISRA clean )


[...] DSP is up and running!

oh yeah!

what rly kept me busy the past 3 hours was to realize that the damn IVA2 (DSP) subsystem has an MMU!

My testcode, which checks that the DSP is actually doing sth, kept failing..until...

 I disabled the damn thing! (the MMU, that is)

I'll open a new thread about this in the dev section tomorrow (or maybe Sunday).

geez.. what a day.

Greetz,

Bastian

 

[bsp]

p.s.:

 as they say..pics or it did not happen.. well here is a .tar.gz that contains my "c64_load" utility +

  a simple demo DSP image, and a boot.txt (tested w/ kernel 3.2.45 / SuperZaxxon 1.55)

 the boot.txt sets up a memory hole @0x86000000..0x88000000, i.e. the additional kernel args are

 "mem=96m@0x80000000 mem=384m@0x88000000" (Rebirth / 1Ghz Pandora)

 resp.

 "mem=96m@0x80000000 mem=128m@0x88000000" (classic Pandora)

 (changing the mem config will be very easy -- actually I usually prefer to place the DSP mem area

  at the end of the ARM mem but that would mean that different DSP image builds would be

  required for the Classic and Rebirth/1GHz editions so the mem hole is probably the way to go)

 Usage: "./c64_load c64p_simple_dm3730.out"

 or

 "./c64_load -v c64p_simple_dm3730.out" (debug prints)

 or

 "./c64_load -vv c64p_simple_dm3730.out" (debug print galore)

 (no special kernel modules needed for now but I'll write a simple ARM<>DSP messaging module soon)

 ..but don't bother--it does not do anything useful, yet. It just tests whether the DSP is actually running!

p.p.s.: although there's still a section called DSPLINKMEM in the .out/.map file, DspLink is NOT needed for this!

p.p.p.s.: don't let the "dm3730" in the image name irritate you -- this should work fine on OMAP3530 as well.

p.p.p.p.s.: last but not least, this software will be licensed under the terms of the GPL (of course!)

c64_load-07Sep2013_3am.tar.gz

 

[bsp]

p.p.p.p.p.s: Due to a stupid typo the "-vv" option (I put a lot of effort into proper parsing of the COFF..) did not work (FILE_NOTFOUND) so here's the final "4am" release for today

(oh my, and I originally thought of introducing myself as "by day I'm an embedded systems developer, by night.... I am Batman!! ..guess that's true after all )

c64_load-07Sep2013_4am.tar.gz

 

[Farox]

Didn't tested all your work (script and DSP stuff) but i think you are really really wellcomed to this community..and all in an bunch of days use...AWESOME

 

[bsp]

Hi Farox/all,

I hope I'll be able to contribute some useful things!

While I did write the DSP loader in just one day (could have been a few hours if I would have taken shortcuts / produced unclean code),
I have to admit that I have worked with similar TI hardware in the 2006-2010 timeframe
(mostly ARM926@297Mhz+C64+@450Mhz platforms running QNX (nice), and Windows CE6 (not my cup of tea)), so I had a certain head start.

If find it really a shame that the DSP seems to be idling around/powered off with practically no application using it.

It is really fast and a good choice for offloading number crunching tasks (e.g. graphics blitters) -- the ARM can do other things in the meantime (physics, sound, ..).

I always found the DspLink software way too overdone (and often causing problems) for what it was used in the end.

The design makes sense if you have several DSPs, connected via PCI/VLYNQ, maybe not even sharing the same memory space with the "GPP" (CortexA8 in this case).

For boards like OMAP3530 (Pandora classic/Rebirth?) and DM3730 (Pandora 1GHz edition), IMHO, it is overkill.

And do not get me started on things like CodecEngine, which is built on top of DspLink and, last time I had to use it, required
a dev. environment that used a JavaScript interpreter written in Java -- that brought my dev.host to its knees back then

Then there's the latency issue.

While I couldn't get DspLink on the Pandora running (already the 2nd API call caused a kernel crash)
(I know others have managed to run it..), I do not know how it performs on the Pandora but on the platforms where I worked on before, the ARM<>DSP messaging latency was quite high (>1ms for an ARM<>DSP roundtrip).

In 2008 I wrote "MiniLink" which replaced DspLink for messaging (just for the fun of it) and that one was able to do over a
million roundtrips per second.

Now that's fast enough for using the DSP as a proper coprocessor (should be even faster on the Pandora).

Well, I think I've totally derailed my own thread and I really should open a new one soon

Today I re-ran my "3am" and "4am" releases (see above) after the Pandora had been powered off over night.

Turns out that accessing the IVA2 MMU2 suddenly caused bus errors.

I spent hours today going through TI manuals to verify my code.

I had already noticed, that there is something fishy about the mmap() in the 3.2.45 kernel -- I already implemented a workaround that maps rather large memory regions instead of single pages because often the mmap() calls reported no error but the application crashed when accessing the mapped/virtual memory.

So, after verifying that my code should work as expected I moved the MMU setup into a kernel module (so I could use
ioremap_nocache()) and voila -- that fixed it.

Please find attached a new snapshot which, besides the "c64.ko" kernel module, now also includes a "go64.sh" script
(anyone remembers that cmd? )

Greetings,
Bastian

c64_load-07Sep2013_7pm.tar.gz

 

[peelie]

hi there regarding the xfce app menu, is it possible for script to check whether menu bar is on autohide and act appropriately? i.e if autohide on then use your script if not then use original script?

thanks

 

[ptitSeb]

Hi bsp.

That DSP work environement you are building is very interresting! Looking forward to this.

 

[levi]

As I understand it, the reason the DSP isn't widely used on Pandora is the need to allocate memory to it at boot.  I guess the 32MB you're allocating wouldn't break the bank even on old 256MB RAM units, but is that enough to keep the DSP busy without tying up the CPU in feeding it (assuming that's even how the relationship works)?

 

[bsp]

@peelie: good point. I'll look into this tomorrow (it's a bug!)

@ptitSeb: it *is* interesting!

@Levi: I chose the current 32MB DSP memcfg because it (hopefully) matches the one used by the "cut for dsp" cfg hardcoded into the Pandora U-Boot. The DSP is a CPU on its own, with its own kernel/OS. It requires a dedicated memory area which needs to be at least ~16k (maybe a lil' bit more). In order to co-operate with the GPP OS (Linux), additional memory is required to share data between the ARM and the DSP (e.g. textures, framebuffers, audio, ..). This usually amounts to a couple of megabytes. In my experience, 32MB should be enough, even for complex applications.

This memory is not "lost to the DSP", it is shared with the ARM.

The DSP operates on physically contiguous memory regions, unlike the host OS, which uses virtual memory. While the DSP *does* have an MMU, AFAIK it supports no more than 32 mem. regions and it is mostly meant as a memory protection against misbehaving DSP programs (so they don't accidentally overwrite the host OS's memory).

 

[ptitSeb]

Yes. Once every is setup and DSP is usable on everyone Pandora, I'll want to try using the DSP for some things (sound plugin for example)