Re: Contribution codes,.... Hey Quim fix it.
"Alfredo J. Fabretti" <[EMAIL PROTECTED]> wrote: > Anyone got his order backordered in the USA store? I'm checking my > order status and it's backordered and the ETA is Feb 12. That's a lot > of time! Lucky you. I just checked and my order status says "Cancellation Requested" and it certainly wasn't requested by me. At least you'll get your device before me. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildon im to X key proxy
"Martin Grimme" <[EMAIL PROTECTED]>: > IIRC the GtkInvisible widget serves exactly this purpose. I tried using it and it doesn't work. The keyboard won't come up with this. Santtu Lakkala <[EMAIL PROTECTED]>: >> - I cannot make a completely hidden window. The best I can do is a >> 1x1 pixel window that shows up as a white dot in the top left >> corner. Making it zero size, moving it off screen, or trying to >> make it transparent don't seem to work. > > Zero size probably doesn't work, but the two other options should. You > might need to do them in the "map", "realize" or "expose-event" signal > handlers (instead of upon creation). Thanks! This does work although it seems a bit like voodoo to me. If I do the window move in the "map" event, it appears to use a reference of the lower right corner. If I do it in realize or expose-event, it uses the top left (which the docs say should be the default). And setting the gravity before the move appears to do nothing. In any case, moving the window -1, -1 in the realize event worked great. Eero Tamminen <[EMAIL PROTECTED]>: > You could use something like matchbox-nest: > http://packages.debian.org/etch/matchbox-keyboard Thanks for the link. That does do almost exactly what I want, but I like the maemo keyboard better than that one. I did find that it uses libfakekey which fakes X keys from unicode characters in pretty much the exact same way that I was doing it so that's good as I can just use the library. But it also doesn't solve the main issues that I'm having. I want the window underneath to be resized and not be covered up by the keyboard. I also need to be able to receive the key focus but force it to lose the focus before sending the fake key. gtk_window_iconify may work but it appears to hide the vkb so it flashes annoyingly. > Unicode covers a much larger range than X keysyms. I'm pretty sure this is not true. In include/X11/keysymdef.h, it says unicode chars are mapped to keysyms by adding 0x0100 and that's how both gdk and libfakekey appear to do it. > The application tells the window manager for which window the keyboard > is opened with an X property I think. Using xprop, the property WM_TRANSIENT_FOR(WINDOW) on the vkb is usually set to the client window. However, if I follow this property value when I run my program, it doesn't change but rather stays set on my window. Yet the target window definitely does change away from my window. I don't know if there's another property you're thinking about, but it seems that even though this property is set, it doesn't necessarily map to the actual client window for the keyboard. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
hildon im to X key proxy
I've been trying to get something like the following to work: - I want to be able to press power, menu or something like that to bring up the on-screen keyboard - Then any keys I press should be sent as normal X key events (i.e. same as if I pressed them on a keyboard) - If I press a hardware key like the menu button, the next key pressed on the vkb is sent as a ctrl character instead Here's my current implementation: - I create a hidden window. I create a new hildon IM context and set the hidden window to be the client. - Keys pressed on the vkb are caught via the "commit" signal and converted to a unicode character. - I use gdk_unicode_to_keyval to convert it to a GDK keyval which I believe has a 1-to-1 mapping to X keysyms - XChangeKeyboardMapping is used to set an arbitrary unused keycode to map to the desired keysym - I then use XTest to generate a fake key of the given keycode It mostly works but there are some issues: - I cannot make a completely hidden window. The best I can do is a 1x1 pixel window that shows up as a white dot in the top left corner. Making it zero size, moving it off screen, or trying to make it transparent don't seem to work. - I set the hidden window to not accept-focus. This is so that when I use XTestFakeKeyEvent, the key is sent to the current top application. However, this also means the hidden window cannot directly get the hardware key presses. I can get it in other ways such as directly from the device file, but it seems like there should be a better solution. If I give the hidden proxy window the focus, I can't figure out how to lose the focus before sending the fake key. - When using it with something like the X terminal which normally pops up the vkb itself, it works for a couple characters (not repeatable how many characters) and then my proxy stops receiving keyboard events. I believe it's because the app realizes it has the focus and it resets the client window for the vkb to be itself. This problem doesn't exist when I use it with something that doesn't normally pop up the vkb (e.g. running emacs over X remotely). If there was some way to determine when the client window for the vkb has changed, that would probably be good enough to reset it back to the proxy window. - Normally, when the vkb pops up, the window underneath is automatically resized. But when doing the above, the top window is not resized so it ends up that the keyboard covers the bottom of the window. How can I force the window underneath to resize? - Is there some way to tell when the vkb has been hidden by the user? Any hints appreciated. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo SDK+ ALPHA-1 development environment released
>We are happy to announce maemo SDK+ Alpha-1 development environment >for maemo developers. Thank you very much for this! After a long upgrade of my machine to gutsy, I got maemo SDK+ running and I can say I definitely like it a lot better than scratchbox 1. I can now compile directly from within emacs and development is just much more pleasant. I couldn't find any problems with it and everything is compiling and running great! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
dbus overhead of unnecessary signals
I'm new to the dbus world and was wondering what the overhead/cost is of many dbus messages. In particular, as an abstract example, suppose I have an event daemon process that could possibly know about n different events and send those out via dbus as n signals. For any particular signal, if some other program is out there listening for the signal, then presumably whatever the dbus overhead is, it's worth it as it's doing what you want it to do. But the real question I have is, what if no one is listening to that signal? Perhaps programs out there are only listening for half of those n signals. For the ignored signals, there is presumably some work for the daemon to listen/process that event, send it out via dbus, the dbus bus daemon receiving the signal and deciding that no one cares about it and dropping it. All of this, in theory, is unnecessary work as no one cares about the message. As one scales the number of such signals and their frequency, my intuition is that it would not be a low cost on an internet tablet as both the event daemon and dbus bus daemon will be constantly waking up and doing unnecessary work. In particular, the work needed to listen/process an event is potentially unbounded. If it is indeed unscalable or a large cost, then an alternative programming model is for the event daemon to not do anything until another program sends it a signal that it's interested in a particular event. Then the server starts sending out the signals for that event, until all programs who have expressed interest disappear or indicate they've lost interest. Clearly, this is programmable in the dbus framework and leads to no unnecessary work being done. However, it also seems redundant for programs to do this as this seems like what the bus daemon is doing. Sending signals to unknown targets seems to me to be a common paradigm in the dbus world but I have not seen a dbus program that avoids sending signals that no one cares about. Why is this? Is there an efficient way to avoid unnecessary dbus signals that doesn't require writing lots of code? It seems ideal if the event daemon could just ask the bus daemon or be notified by it when someone is listening for a particular signal. For the maemo developer, this choice makes it necessary to decide whether some program out there likely wants to know about a particular signal and thus only emit those signals. However, it seems to be much more in the spirit of dbus signals to just emit all the signals you could possibly think of emitting and let the receivers decide what they want to listen to. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
> So why not just port mpd server component to maemo and be done with it? Done. https://garage.maemo.org/projects/mpd > There are 5 (five!) web based mpd clients listed on their site and 13 other > ones. > > In addition meamo is already at, what, 4 - 5 media players? There is so much > stuff out there talented developer like yourself can focus on... I think one thing that would help mpd on maemo would be implementing gstreamer support for it so it could decode using the dsp rather than the cpu. But otherwise, it works great. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
> I've decided that I'd really like to separate the frontend code from the > backend code so we can have multiple frontends (pygame, gtk, etk, cli, WWW, > etc). > > This would mean that the Kagu backend process would be a daemon (aka a > service, depending on your education environment). > And the frontends would communicate with the backend process somehow. I see > a few possibilities here: > > 1.) Rpc (aka web services) > 2.) Dbus > 3.) Direct SQLite DB interaction I think this is a great idea. I personally use mpd just for this reason. In fact, why not just use the mpd protocol over net sockets? You'd immediately get a ridiculously large number of front-end clients and it would work over the net: http://mpd.wikia.com/wiki/Clients ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: selectively disabling virtual keyboard
Julius Luukko <[EMAIL PROTECTED]> wrote wisely: > Hello Austin and all, > > I don't think that synthetizing key presses is the way to go. You can > get a similar effect as is in the device lock screen by setting your > GTK_ENTRY's editable property to FALSE: > > myentry=gtk_entry_new(); > gtk_editable_set_editable(GTK_EDITABLE(myentry), FALSE); > > Then use gtk_editable_set_text, gtk_editable_insert_text etc. to set > to text in your text box according to your button presses. Thanks Julius. This does work almost similarly to the device lock screen. However, it is not identical in that if the GtkEntry has visibility=false (i.e. it's a password box like the device lock dialog), then when you use gtk_editable_set_text or gtk_editable_insert_text, asterisks are directly inserted. The device lock box shows the inserted text briefly before turning into an asterisk (which I find pretty helpful to know whether you actually hit the button you wanted to hit). That's why I asked about synthesizing key presses as that's what it looks like the device lock screen is doing. In any case, this is a minor issue so I don't think I'll worry about it. I mainly didn't want the virtual keyboard coming up and squishing my window and that problem seems to be solved. Thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: selectively disabling virtual keyboard
> On Sat, Nov 24, 2007 at 10:28:28AM -0500, Austin Che wrote: >> Is is possible to create a text box that doesn't show the virtual >> keyboard when it receives the focus? > > Make it read-only. I don't think this is exactly the effect I need. I want something like the "device lock" screen (e.g. control panel->device lock->change lock code). The text box doesn't seem to be read-only because the text in it doesn't get grayed out. I guess it is simply unable to receive the focus. However, the buttons somehow also emulate a key press for the text box. The buttons don't just set the text directly as the number that is entered shows up for a brief moment then turns into an * which doesn't happen if I just programmatically change the text in the box. So assuming that disabling a text box from receiving the focus is sufficient to prevent the on-screen keyboard from showing up, what's the best way to send a synthetic key press to the text box? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
selectively disabling virtual keyboard
Is is possible to create a text box that doesn't show the virtual keyboard when it receives the focus? For example, if it were possible to fake the system into thinking a hardware keyboard was connected when a particular text box is activated and then disconnect the fake keyboard on focus loss, that would probably be sufficient. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dealing with non-GTK windows
Tapani Pälli <[EMAIL PROTECTED]> wrote: >> - Is it possible to force such a window into fullscreen? I don't >> care if it needs to be done manually. For example, is it >> possible to have a program that takes whatever window is >> currently on top/in focus and makes it fullscreen? >> > Yes, by giving hints to window manager. This can be achieved by setting > _NET_WM_STATE to _NET_WM_STATE_FULLSCREEN. Thanks! I found it easier to use gdk_window_foreign_new and then gdk_window_fullscreen. I've now got a semi-working hack using my powerlaunch program to force any window into fullscreen by pressing power,fullscreen. For example, I can now run NX in fullscreen and get a full KDE desktop on the N800: http://austinche.name/maemo/nx-fullscreen.png The one remaining issue I have is how to reliably get the ID of the top window or focused window. I'm using XQueryPointer to get the window under the pointer but it appears to sometimes give windows that no longer exist (cache?) and thereby giving BadWindow errors. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to detect if the headphones are plugged?
> Here's how I did it in Python, took some testing. > https://www.guardiani.us/projects/kagu/changeset/670 Thanks Kemal, that works great. The trick was to actually read the data from the file to cancel the condition... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to detect if the headphones are plugged?
> g_io_add_watch() if you're using glib, inotify if you're not (man
> inotify(7)).
>
> Regards: David
Thanks for the suggestion but I can't get this to work. If I use:
GIOChannel *io =
g_io_channel_new_file("/sys/devices/platform/gpio-switch/headphone/state", "r",
NULL);
g_io_add_watch(io, G_IO_IN|G_IO_OUT|G_IO_PRI|G_IO_ERR|G_IO_HUP|G_IO_NVAL,
test_io_watch, NULL);
and I print out the GIOCondition in test_io_watch, I get a
constant stream (number 10) with nothing extra seen when the headphone
is plugged in or out. Using individual conditions leads to either
the function never being triggered or always being triggered. What
should I be watching for?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: how to detect if the headphones are plugged?
Daniel M German <[EMAIL PROTECTED]> wrote: > is there a way to detect if the headphones are plugged? > > I am irritated that music playing software does not pause when the > headphones are removed (like the ipod) and would like to write a patch > to make it an option. ~ $ cat /sys/devices/platform/gpio-switch/headphone/state connected ~ $ cat /sys/devices/platform/gpio-switch/headphone/state disconnected I'd also be interested to know if there's a way to be notified about this rather than just polling. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
dealing with non-GTK windows
Some questions about non-GTK windows that applications may show: - Is it possible to force such a window into fullscreen? I don't care if it needs to be done manually. For example, is it possible to have a program that takes whatever window is currently on top/in focus and makes it fullscreen? - The windows don't show up in the task switcher. Is there some way of at least finding and bringing a window back up to the front via a program/command-line tool, perhaps matching on window title or other properties? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
working NX client
I've seen previous discussions about porting NX but I couldn't find any actual code I could run. So I went ahead and got NX semi-working on the N800. See KDE running: http://austinche.name/maemo/nx.png I'm using nxlaunch as the front-end http://www.esfnet.co.uk/index.php?page=nxlaunch It doesn't work in fullscreen mode (the window just disappears and I can no longer find it even though the process is running). There are some other bugs with the programs that need manual tweaking, e.g. editing the configuration via the UI can crash nxlaunch so I manually edit config files. As I don't have the time, if anyone wants to take it to a state where it could actually be released, all components are open-source. nxproxy, nxcomp, nxssh: http://www.nomachine.com/sources.php nxcl and nxlaunch: http://svn.berlios.de/viewcvs/freenx/ My compiled binaries: http://austinche.name/maemo/packages/nxcl_0.1_armel.deb http://austinche.name/maemo/packages/nxlaunch_0.1_armel.deb This includes the necessary binaries from NX. It should just be extracted from / http://austinche.name/maemo/packages/nxclient-armel.tar.gz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
>> to do it (not using dbus however) and there's no race with
>> DSME. It stays off until the touchscreen or key is pressed. Here's
>> code that'll blank the screen:
>> #include
>> #include
>> #include
>> int main(int argc, char **argv) {
>> int fb = open("/dev/fb0", O_NONBLOCK);
>> if (fb < 0) perror("Error opening /dev/fb0");
>> if (ioctl(fb, FBIOBLANK, VESA_POWERDOWN) < 0) perror("Blanking error");
>> close(fb);
>> }
>>
>
> But that's run as root, right? I need to be able to blank from
> userspace without root as a normal user.
It works for me as a normal user but I no longer remember whether
I had either added 'user' to the video group or otherwise changed
the permissions on /dev/fb0 so that the user had extra
permissions.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
> On Fri, Sep 14, 2007 at 12:39:18PM -0400, ext Jesse Guardiani wrote:
>> I'd personally love to see DSME open sourced.
>
> Oh, me too. Nothing I've said on this list should indicate otherwise.
>
>> In particular, there are
>> screen ON/OFF/Notify
>> events that it sends/receives via dbus that I'd love to extend. For
>> example, I've got a DSME
>> related ticket that I'd like to close using dbus, but that probably
>> isn't possible with DSME as-is:
>> https://www.guardiani.us/projects/kagu/ticket/52
>
> You can just bypass DSME and deal with omapfb directly: see
> asm-arm/arch-omap/omapfb.h. Note that DSME does this every 1s or so, so
> you're in a godawful race, so you might just have to nuke the blanking
> plugin or something.
Jesse,
I had previously looked at blanking the screen and figured out how
to do it (not using dbus however) and there's no race with
DSME. It stays off until the touchscreen or key is pressed. Here's
code that'll blank the screen:
#include
#include
#include
int main(int argc, char **argv)
{
int fb = open("/dev/fb0", O_NONBLOCK);
if (fb < 0) perror("Error opening /dev/fb0");
if (ioctl(fb, FBIOBLANK, VESA_POWERDOWN) < 0) perror("Blanking error");
close(fb);
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mpd
Jeffrey Barish <[EMAIL PROTECTED]> wrote: > I find that uncommenting any of the audio output sections seems to do the > trick. I have the ALSA section uncommented now. But you weren't actually able to play anything right? I got a segfault during the playing of a file with alsa, not on the startup. Running mpd manually and then starting it playing, I see: decoder PID: 1895 decoder (or child) got SIGTERM copyMpdTagToOB: !acceptMetadata || !tag main process got SIGCHLD SIGCHLD caused by player process player process died from signal: 11 So I'd be interested to know if you can actually get it to output sound via alsa (assuming you get it to index files below). > mpd is running now (according to ps), but I still can't get it to index any > sound files. I stuck a symbolic link in /var/lib/mpd/music to the > directory containing my soundfiles (ogg). I run mpd --create-db. The only > output I get is: > > current locale is "C" > setting filesystem charset to ISO-8859-1 How did you get this output? Did you try running mpd manually with: mpd --no-daemon --stdout --verbose --create-db > The files in /var/log/mpd are empty. Everything is owned by user mpd and > mpd has permission to read and write. I must have missed an important > step. Any idea? Are you sure that mpd has permission to read the directory containing your soundfiles? I'd try just copying over a file or two to /var/lib/mpd/music to test. I also haven't tested with ogg files so try copying over a mp3 file also to test. Also, as you manually ran adduser, you may have also missed out on some step in the installation script. Perhaps you could try installing the adduser package and reinstalling the package. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: mpd
>> So I went ahead and ported mpd and mpg321 to maemo. In >> case anyone else wants these packages as I couldn't find them >> already out there: http://austin.mit.edu/maemo > > chage: can't open shadow password fileStopped: `/usr/bin/chage -M 9 mpd' > returned error code 1. Exiting. I don't know where that is coming from as I don't think any of the mpd scripts calls chage. It does use adduser so that should be added to the dependency list. > I tried creating the mpd user by running adduser manually, but then I get > segmentation fault whenever I run mpd. Creating the mpd user manually should let you run it. I would edit /etc/mpd.conf and uncomment the libao section. I was getting segfaults with alsa output while ao output worked fine. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Jesse Guardiani <[EMAIL PROTECTED]> wrote: > Austin Che wrote: >> Ok thanks. So I went ahead and ported mpd and mpg321 to maemo. In >> case anyone else wants these packages as I couldn't find them >> already out there: http://austin.mit.edu/maemo >> mpd uses about 10% of the cpu and mpg321 uses about 20% of >> the CPU >> even though they should be both using libmad. mpg321 seems to skip >> a bit just switching apps but renicing it a bit appeared to get >> rid of the skipping. I'm not sure why mpd seemed to do better in >> general. Also, for some reason, using alsa output with mpd didn't >> work (apparently segfaults) while libao output worked fine. > > Is that on the n800 or 770? My experience has been that mplayer with > ffmp3 typically gets about 16% CPU during playback on an n800 while > playing back a very high quality VBR mp3. n800 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Koen Kooi <[EMAIL PROTECTED]> wrote: > Jesse Guardiani schreef: > >>> And the related question is: given an existing program that sends >>> stuff out to ALSA and doesn't use gstreamer, how difficult is it >>> generally to port it so that it works properly? >> >> No porting necessary, really. mplayer comes with a decoder called >> libmp3. It's not optimized for ARM or anything, and it compiles without >> any problems. We don't use it in Kagu for A2DP though because there is >> another decoder out there called ffmp3 which doesn't use floating point >> math, so it's a little more efficient on ARM. > > use libmad (-ac mad), that works great on arm and x86. Ok thanks. So I went ahead and ported mpd and mpg321 to maemo. In case anyone else wants these packages as I couldn't find them already out there: http://austin.mit.edu/maemo mpd uses about 10% of the cpu and mpg321 uses about 20% of the CPU even though they should be both using libmad. mpg321 seems to skip a bit just switching apps but renicing it a bit appeared to get rid of the skipping. I'm not sure why mpd seemed to do better in general. Also, for some reason, using alsa output with mpd didn't work (apparently segfaults) while libao output worked fine. I'll try using mpd with glurp, mmpc, or some other client for a bit and see if I can get a feel for whether the battery usage is substantially worse than using canola. But so far, this setup with mpd is more like how I want my music player to be and fixes some of the annoyances I've had with all the other music players I've tried: no unnecessary scanning for new songs and no unexplainable errors that stop or freeze the playing of the music some of the time. All that is needed is a good client. glurp seems a bit unresponsive but mmpc isn't too bad. If anyone knows of any other good mpd client (there is a ridiculously large number of clients http://mpd.wikia.com/wiki/Clients) or one that could be easily ported, please let me know. I was looking at the sonata client which requires pygtk 2.6 and gtk 2.6 but I'm not sure if maemo supports these versions as I couldn't get it to install: http://mpd.wikia.com/wiki/Client:Sonata ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Jesse Guardiani <[EMAIL PROTECTED]> wrote: > And no, before you ask, I don't think it's not Nokia's fault. gstreamer > is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3 > decoders... life would be easier for all of us... I've been wondering: what is the performance hit for not going through gstreamer? So based on my understanding, going through gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded on the cpu and sent out through alsa, which of the following is likely to be true: - The CPU wouldn't be able to handle it (playback would skip) - The CPU could handle it just as well as the DSP but the rest of the system might be less usable - The battery life would decrease (how much?) - some other reason this wouldn't work well? And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? By this, I'm thinking of a typical C program that plays mp3 files. Would it likely require a complete rework of the code structure or is it probably a "trivial" replacement of function calls? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
