Re: Porting fltk-app
Hi, Thanks for your answer, and sorry for my late answer, but I am a bit busy with my studies as well. Eero Tamminen wrote: Hi, ext Tapani Pälli wrote: I am trying to port an FLTK (www.fltk.org) application to N770/N800. I got FLTK compiled and the application as well, but when I run the application, it is not managed by Matchbox. That is, the program is not shown in the taskbar and the keyboard will not pop up. I have tried to hack FLTK according to the code snippets https://garage.maemo.org/snippet/detail.php?type=snippetid=3 and https://garage.maemo.org/snippet/detail.php?type=snippetid=4 but without luck. What do I need in order for Matchbox being aware of my program? The window is being managed by matchbox. Maemo input-methods (keyboard, hwr) use their own protocol to communicate directly with gtk-widgets. You have to implement this protocol in text-entry fltk-widgets. Basically it means sending an X to the input method window when the widget wants the input method to show itself. In the Maemo Gtk this happens when user taps to a widget. Maemo Input Method framework was just opened, so now other widget sets like Fltk or Qt can be fully ported to Maemo. The IM protocol source for widget - input method communication is here: https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-input-method-framework/src/ I will look into this. In order to get program shown in taskbar (which is a pager, not a component of window manager) you have to provide valid .desktop file. Instructions to do this is in maemo.org documentation. I found an example on a .desktop file and (basically) copied it. When I start the program, the notification says Launching ThinLinc (the program), but nothing happens. I also tried to make a service file - but with no luck. ~Jørn ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: conflicts between row-activated and button-press-event signal on GtkTreeView
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zhu, Peter J wrote: I'm having problems with mouse click processing of GtkTreeView. I would like to have different callback to single click and double click. But once I connect singal to button-press-event, no row-activated signal is received. I would guess your button-press-event-handler returns TRUE. For most Gdk/Gtk+ signals, returning TRUE means that the event has been handled, and it's emission is stopped -- thus it never reaches the handler in GtkTreeView. Try returning FALSE. ;) - -- Santtu Lakkala -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFG6jQEX9Rc0+po4p0RAtAMAJsEuNd8k7X/gbioT3XOgjScJqFUJQCfc2Eq 782EgwHiuTHQbX8pfgfJucE= =O2Gv -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Porting fltk-app
ext Jørn Christensen wrote: Hi, Thanks for your answer, and sorry for my late answer, but I am a bit busy with my studies as well. Eero Tamminen wrote: Hi, ext Tapani Pälli wrote: I am trying to port an FLTK (www.fltk.org) application to N770/N800. I got FLTK compiled and the application as well, but when I run the application, it is not managed by Matchbox. That is, the program is not shown in the taskbar and the keyboard will not pop up. I have tried to hack FLTK according to the code snippets https://garage.maemo.org/snippet/detail.php?type=snippetid=3 and https://garage.maemo.org/snippet/detail.php?type=snippetid=4 but without luck. What do I need in order for Matchbox being aware of my program? The window is being managed by matchbox. Maemo input-methods (keyboard, hwr) use their own protocol to communicate directly with gtk-widgets. You have to implement this protocol in text-entry fltk-widgets. Basically it means sending an X to the input method window when the widget wants the input method to show itself. In the Maemo Gtk this happens when user taps to a widget. Maemo Input Method framework was just opened, so now other widget sets like Fltk or Qt can be fully ported to Maemo. The IM protocol source for widget - input method communication is here: https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-input-method-framework/src/ I will look into this. In order to get program shown in taskbar (which is a pager, not a component of window manager) you have to provide valid .desktop file. Instructions to do this is in maemo.org documentation. I found an example on a .desktop file and (basically) copied it. When I start the program, the notification says Launching ThinLinc (the program), but nothing happens. I also tried to make a service file - but with no luck. You have to copy .desktop file to /usr/share/applications/hildon directory. What version(s) of Maemo are you using? There used to be some issues with .desktop files not having _exactly_ correct syntax .. ~Jørn ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers // Tapani ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
Simon Pickering wrote: Hi Neil, I happened to come across this commit mailing list: https://garage.maemo.org/pipermail/dsm-commits/ Is this related to the 770/N800 closed source DSME code at all? It looks like it might be. (I have no strong interest in this myself, but I know that from time to time questions are asked about what DSME is, so I thought this might be useful to point out...) Good spot, I was wondering what goes on inside DSME. The first post is a large patch containing the entire source from the looks of it. Oh, it is gone. Page not found. I was very interested in that :-( Currently there is an issue with bootmenu network recovery mode over usb in initfs with N800. 770 works fine but initfs (dsme?) in N800 doesn't like staying too long in initfs and powers the device off after some random time. It is good enough to enter few commands but not good enough to save/restore rootfs. I'd want to keep dsme happy somehow while staying in initfs for longer time. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
I happened to come across this commit mailing list: https://garage.maemo.org/pipermail/dsm-commits/ Is this related to the 770/N800 closed source DSME code at all? It looks like it might be. The first post is a large patch containing the entire source from the looks of it. Oh, it is gone. Page not found. I was very interested in that :-( Still there for me: https://garage.maemo.org/pipermail/dsm-commits/2006-July/00.html Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
Simon Pickering wrote: I happened to come across this commit mailing list: https://garage.maemo.org/pipermail/dsm-commits/ Is this related to the 770/N800 closed source DSME code at all? It looks like it might be. The first post is a large patch containing the entire source from the looks of it. Oh, it is gone. Page not found. I was very interested in that :-( Still there for me: https://garage.maemo.org/pipermail/dsm-commits/2006-July/00.html I can see listinfo here https://garage.maemo.org/mailman/listinfo/dsm-commits but clicking DSM-commits Archives link brings me a nice Garage page with blue 'PAGE NOT FOUND' text and search box. Maybe you have it cached? Same for https://garage.maemo.org/mailman/listinfo/dsm-devel It doesn't matter whether I am logged-in to garage or not. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
Frantisek Dufka wrote: Same for https://garage.maemo.org/mailman/listinfo/dsm-devel It doesn't matter whether I am logged-in to garage or not. Same 'page not found' with IE on XP, Firefox on XP, Firefox and lynx on Ubuntu. However I did have success with wget but that one is quite hard to use to browse list archives :-) Something strange is happening here. Either you guys are in some inner circle or the problem is on my side. I suppose the latter. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On Thu, 2007-09-13 at 23:02 +0100, ext Neil Jerram wrote: I happened to come across this commit mailing list: https://garage.maemo.org/pipermail/dsm-commits/ Hi Neil, nice catch. :) Bad news We have made those archives private and they are now not publicly accessible. This was an internal exercise done last year about opensourcing the DSME framework, and shouldn't have gone to the public. Good news We are still working on opensourcing part of the hardware management stack, but considering a different approach: http://ohm.freedesktop.org/ . This is a public and open source project, go there to check the details. No decisions at this point, please let us some time. For us the code you saw is practically an end road, since we are exploring other paths. Thanks for finding the hole though, this is always useful. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
Oh, it is gone. Page not found. I was very interested in that :-( Still there for me: https://garage.maemo.org/pipermail/dsm-commits/2006-July/00.html I can see listinfo here https://garage.maemo.org/mailman/listinfo/dsm-commits but clicking DSM-commits Archives link brings me a nice Garage page with blue 'PAGE NOT FOUND' text and search box. Maybe you have it cached? Yes, looks like I did have it cached, my apologies. Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: DSP vs. ARM endianness and struct packing
Using the following struct on the DSP-side:
typedef struct endian_test_struct {
unsigned long iamulong1;
unsigned int iamuint1;
unsigned int iamuint2;
unsigned long iamulong2;
unsigned int iamuint3;
unsigned long iamulong3;
} endian_test_struct;
I should qualify this:
On the DSP the types have the following sizes:
Char = short = int = 16bit
Long = 32bit
For comparison here's the same struct filled and viewed on
the ARM (with no
optimisation flags):
Ah, my mistake, I thought I'd altered the types of the struct members on the ARM
side to be the same sizes as on the DSP side; I was going to email and give the
correct struct for the ARM side, but it looks like I copied the wrong one (i.e.
the same member types which are all 32bit on the ARM). So ignore the ARM results
for now, I'll re-do those.
/me slopes away slightly embarrassed
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
DSP vs. ARM endianness and struct packing
Hello all,
In my investigations of whether I can pass structs through shared memory (after
performing endianness swaps), I looked at the precise endianness of the two
processors and struct packing. This may be of use to someone, so I thought I'd
summarise it here.
I'm not sure if struct packing may be done differently on the ARM depending on
the -O level, probably though.
Anyway, this is what one sees:
Using the following struct on the DSP-side:
typedef struct endian_test_struct {
unsigned long iamulong1;
unsigned int iamuint1;
unsigned int iamuint2;
unsigned long iamulong2;
unsigned int iamuint3;
unsigned long iamulong3;
} endian_test_struct;
Then giving it values and copying it into the shared memory region (all on the
DSP side):
ets.iamulong1 = 0x12345678; // 32 bits
ets.iamuint1 = 0x1234; // 16 bits
ets.iamuint2 = 0x1234; // 16 bits
ets.iamulong2 = 0x12345678; // 32 bits
ets.iamuint3 = 0x1234; // 16 bits
ets.iamulong3 = 0x12345678; // 32 bits
One obtains the following when reading the data on the ARM side:
Byte #: Hex
Byte 0: 34
Byte 1: 12
Byte 2: 78
Byte 3: 56
Byte 4: 34
Byte 5: 12
Byte 6: 34
Byte 7: 12
Byte 8: 34
Byte 9: 12
Byte 10: 78
Byte 11: 56
Byte 12: 34
Byte 13: 12
Byte 14: 0
Byte 15: 0
Byte 16: 34
Byte 17: 12
Byte 18: 78
Byte 19: 56
So the data on the DSP are bigendian, but as the 16bit char (=int) is the
smallest type, one doesn't see that within this type the data are stored in
little-endian form. In addition, data are packed into 32bit chunks (i.e. one
32bit value or 2x 16bit values), but if they spread across a boundary there is
padding inserted (see the gap between the last (16bit) int and the last (32bit)
long). I have looked at a similar struct with a (16bit) int on the end and the
struct was then padded to make it a multiple of 32bits long and the padding data
were not 0s.
For comparison here's the same struct filled and viewed on the ARM (with no
optimisation flags):
Byte #: Hex
Byte 0: 78
Byte 1: 56
Byte 2: 34
Byte 3: 12
Byte 4: 34
Byte 5: 12
Byte 6: 0
Byte 7: 0
Byte 8: 34
Byte 9: 12
Byte 10: 0
Byte 11: 0
Byte 12: 78
Byte 13: 56
Byte 14: 34
Byte 15: 12
Byte 16: 34
Byte 17: 12
Byte 18: 0
Byte 19: 0
Byte 20: 78
Byte 21: 56
Byte 22: 34
Byte 23: 12
In this case we see that the data are truly little-endian, and that all struct
members are placed into a 32bit space, with packing if they are too short.
To summarise, don't try passing structs from ARM to DSP via shared memory unless
all the values are 32bits or you are careful with the order of the struct
members. Either way bit swapping is obviously required.
Cheers,
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs. ARM endianness and struct packing
Simon
What happens if you pack the structure as in
typedef struct __attribute__ ((packed)) endian_test_struct {
Bob
On Friday 14 September 2007 12:08, Simon Pickering wrote:
Using the following struct on the DSP-side:
typedef struct endian_test_struct {
unsigned long iamulong1;
unsigned int iamuint1;
unsigned int iamuint2;
unsigned long iamulong2;
unsigned int iamuint3;
unsigned long iamulong3;
} endian_test_struct;
I should qualify this:
On the DSP the types have the following sizes:
Char = short = int = 16bit
Long = 32bit
For comparison here's the same struct filled and viewed on
the ARM (with no
optimisation flags):
Ah, my mistake, I thought I'd altered the types of the struct members on
the ARM side to be the same sizes as on the DSP side; I was going to email
and give the correct struct for the ARM side, but it looks like I copied
the wrong one (i.e. the same member types which are all 32bit on the ARM).
So ignore the ARM results for now, I'll re-do those.
/me slopes away slightly embarrassed
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
--
V +44 (0) 1296 747667
F +44 (0) 1296 747557
C +44 (0) 7860 406093
Diamond Consulting Services Ltd
Dinton
Aylesbury
Bucks, HP17 8UG
England
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On 9/14/07, Simon Pickering [EMAIL PROTECTED] wrote: Oh, it is gone. Page not found. I was very interested in that :-( Still there for me: https://garage.maemo.org/pipermail/dsm-commits/2006-July/00.html I can see listinfo here https://garage.maemo.org/mailman/listinfo/dsm-commits but clicking DSM-commits Archives link brings me a nice Garage page with blue 'PAGE NOT FOUND' text and search box. Maybe you have it cached? If you still have it cached, and could describe how it works to someone who hasn't seen it, it would be an opportunity for the community to work on a replacement. This would have some positive outcomes for both users and Nokia. For users: 1) We'd have an open-source replacement for DSME, without having to wait for Nokia to decide what they're going to do w/ OHM. 2) We'd have an open-source replacment for DSME in case Nokia decides _not_ to use OHM. 3) We'd have an entirely open-source alternative to OHM in case Nokia decides to leverage the LGPL license of OHM to keep modules closed. For Nokia: 1) the community does the work of creating an open-source replacement for DSME and maintaining it 2) a streamlined decision-making process (no involvement of Nokia lawyers) Dave ___ 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 11:15:52AM -0400, ext Dave Neuer wrote: If you still have it cached, and could describe how it works to someone who hasn't seen it, it would be an opportunity for the community to work on a replacement. The D-Bus API is a very good start: have you considered looking at that? I don't see anything stopping anyone from starting work on DSME, now, commits or no (you really don't want questions about the legitimacy of your code). Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On 9/14/07, Dave Neuer [EMAIL PROTECTED] wrote: On 9/14/07, Daniel Stone [EMAIL PROTECTED] wrote: On Fri, Sep 14, 2007 at 11:15:52AM -0400, ext Dave Neuer wrote: If you still have it cached, and could describe how it works to someone who hasn't seen it, it would be an opportunity for the community to work on a replacement. The D-Bus API is a very good start: have you considered looking at that? ... it's tiresome for me to hear well-intentioned Nokia employees such as yourself and Igor insist I should just look at D-Bus or hints dropped on mailing lists and guess what closed Nokia software does. Sorry if that reply was a little hasty and harsh, and to clarify: if you, Igor or anyone else at Nokia with knowledge of how any piece of closed Nokia software that shipped with the 770 works will promise to support me when I run into snags or need more information, just guess might be reasonable. Absent such a promise, it sounds an awful lot like something Dick Cheney once said to the senior Senator from Vermont of the floor of the US Senate. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On 9/14/07, Daniel Stone [EMAIL PROTECTED] wrote: On Fri, Sep 14, 2007 at 11:15:52AM -0400, ext Dave Neuer wrote: If you still have it cached, and could describe how it works to someone who hasn't seen it, it would be an opportunity for the community to work on a replacement. The D-Bus API is a very good start: have you considered looking at that? I don't see anything stopping anyone from starting work on DSME, now, commits or no (you really don't want questions about the legitimacy of your code). Questions about legitimacy aren't a problem as long as the answer is it's legitimate. I'm not aware of any jurisdictions where it is illegal for me to write software based on a description of what some other software does (i.e., clean-room reverse-engineering), or for someone to describe software they've seen the code to. Obviously anyone considering doing either of those things should check for themselves whether it is legal in their jurisdiction. Of course, I completely agree that the actual code that was at the site cannot, and _should_ not, be redistributed without Nokia's permission. But honestly, just as I'm sure it's tiresome for Nokia employees to hear me constantly harp on the closed nature of the IT OS, it's tiresome for me to hear well-intentioned Nokia employees such as yourself and Igor insist I should just look at D-Bus or hints dropped on mailing lists and guess what closed Nokia software does. Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
home plugin osso initialization
I've written a home plugin that wants to use libosso calls. Does it need to explicitly initialize osso (via osso_initialize()) or should it use the osso_context_t from hd-desktop or hd-wm? If the later, how does it get the osso context? Thanks for any help. Bill ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
On 9/14/07, Daniel Stone [EMAIL PROTECTED] wrote: Hi, DSME doesn't do anything complex, really. Looking at the API, it's trivial to reimplement, but as far as I can tell, no-one's ever started. Of course, it should be open, but the fact that no-one's even tried probably says something about how desirable/essential it is to current community efforts, to be honest. It's true, and there are quite a few possible reasons for that. It's possible everyone is happy with the way Nokia is supporting the 770. It's possible that people who aren't happy, but aren't getting paid to work on the IT OS for 770 are worried that they will start, run into obstacles and a lack of information and have wasted their time -- DMSE is just one of several components that need to be replaced in order to have a completely-open 770, right? At any rate, your larger point is correct: it's not clear -- to me, at least -- that there is any kind of community of 770 users who care enough to gel arround such an effort and make decisions about things like goals, compatability etc. So, if the issue is all about my own dissatisfaction, being cranky on the mailing list and letting my 770 collect dust in my office in the attic is a perfectly acceptable solution. Dave ___ 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 11:44:40AM -0400, ext Dave Neuer wrote: But honestly, just as I'm sure it's tiresome for Nokia employees to hear me constantly harp on the closed nature of the IT OS, it's tiresome for me to hear well-intentioned Nokia employees such as yourself and Igor insist I should just look at D-Bus or hints dropped on mailing lists and guess what closed Nokia software does. Hi, DSME doesn't do anything complex, really. Looking at the API, it's trivial to reimplement, but as far as I can tell, no-one's ever started. Of course, it should be open, but the fact that no-one's even tried probably says something about how desirable/essential it is to current community efforts, to be honest. Implementing something relatively trivial is definitely vastly easier than reverse-engineering current-generation video cards, let me tell you. Cheers, Daniel signature.asc Description: Digital signature ___ 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:19:15PM -0400, ext Dave Neuer wrote: It's possible that people who aren't happy, but aren't getting paid to work on the IT OS for 770 are worried that they will start, run into obstacles and a lack of information and have wasted their time -- DMSE is just one of several components that need to be replaced in order to have a completely-open 770, right? There's no real such thing as a waste of time in this regard. If you don't manage to completely replace the entire thing, you still have something, you may have still learned something, and you may have helped convince people that there are people who actually want to work on DSME (and thus, from a business point of view, a benefit to open-sourcing it). As I said before, DSME isn't even terribly difficult to reverse-engineer. I'm saying this as someone who's read the DSME code, and also the DSME API. The closed components I can think of (barring anything high up in userspace: browser, email, UI, whatever) are nolo, DSME, and BME. BME could be done, though you want to watch your battery for signs of puffiness. nolo is very difficult, though it's entirely predictable, so while it could be done, it'd be extremely tough. DSME is trivial. Cheers, Daniel signature.asc Description: Digital signature ___ 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. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
Daniel Stone wrote: On Fri, Sep 14, 2007 at 12:19:15PM -0400, ext Dave Neuer wrote: It's possible that people who aren't happy, but aren't getting paid to work on the IT OS for 770 are worried that they will start, run into obstacles and a lack of information and have wasted their time -- DMSE is just one of several components that need to be replaced in order to have a completely-open 770, right? There's no real such thing as a waste of time in this regard. If you don't manage to completely replace the entire thing, you still have something, you may have still learned something, and you may have helped convince people that there are people who actually want to work on DSME (and thus, from a business point of view, a benefit to open-sourcing it). As I said before, DSME isn't even terribly difficult to reverse-engineer. I'm saying this as someone who's read the DSME code, and also the DSME API. The closed components I can think of (barring anything high up in userspace: browser, email, UI, whatever) are nolo, DSME, and BME. BME could be done, though you want to watch your battery for signs of puffiness. nolo is very difficult, though it's entirely predictable, so while it could be done, it'd be extremely tough. DSME is trivial. I'd personally love to see DSME open sourced. 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 -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Fwd: Re: /dev/dsp]
I compiled esound-clients from debian tar (without patch) copied esddsp, libesd.so.0 and libesddsp.so.0 to the places and started ./esddsp ./gtick and everything works fine. Detlef Am Dienstag, den 11.09.2007, 21:22 +0200 schrieb Detlef Schmicker: Hi, I have some progress: I compiled alsa-oss (oos emulation for alsa) on maemo and tried to start gtick with Nokia-N800-26:/home/user# ./aoss ./gtick dsp_protocol_open_node(): Could not open pcm device file /dev/dsptask/pcm3 As you see, it is the actual firmware on N800. The device is present in /dev. Do you have any idea, what might be the problem. I did not find any simelar problem. Detlef E-Mail-Nachricht-Anlage, Weitergeleitete Nachricht - Re: /dev/dsp Weitergeleitete Nachricht Von: Detlef Schmicker [EMAIL PROTECTED] An: Marc-Andre Lureau [EMAIL PROTECTED] Betreff: Re: /dev/dsp Datum: Mon, 10 Sep 2007 16:34:25 +0200 HI, Thanks, I was afraid of this :-) No, I just compiled in scretchbox and I was able to start it on N800. Do you know of any projects, which might make a bridge from oos /dev/dsp device to GStreamer, ALSA or esd?! (I am not very familar with sound systems up to now) Detlef Am Montag, den 10.09.2007, 11:35 +0300 schrieb Marc-Andre Lureau: Hi! GTick is seriously cool for musicians, especially if it is on a n770/800 Excellent idea :) I can see from the source that GTick only works with OSS. Unfortunately, OSS is not supported... Extra work will be needed. An application can use GStreamer, ALSA or esd: http://maemo.org/development/documentation/how-tos/3-x/multimedia_architecture.html Is your progress already published on a git branch, or garage? Cheers, On Sat, 2007-09-08 at 20:17 +0200, ext Detlef Schmicker wrote: Hay, I tried to port gtick (metronom application). I need to enter the sound device, but there is no /dev/dsp availible. Is there an easy way to install one?! Thanks Detlef ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Looks like .maemo.org cert has expired
SSL certs on maemo.org expired on the 12th? -- Tony Maro http://www.maro.net/ossramblings.php ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs. ARM endianness and struct packing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I did some experimentation a while back with DSP - ARM communication via mmap'ed memory, in my case I was working on using the DSP for rgb to yuv conversion. Another big gotcha to look out for is 64k boundaries. The DSP (at least in the 770) just can't naturally deal with object bigger than 64k, so you will get very bizarre results if you run into this limitation. - -- Buck -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG6tzNPrrWIMa4SMsRAkbuAJ95XfnsZicLMAs39V5CK0Dce7L62ACdF4ao ZW5B/cKDkPIQ1JG+XUcHwbA= =En3x -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs. ARM endianness and struct packing
On 14 September 2007, Charles 'Buck' Krasic wrote: I did some experimentation a while back with DSP - ARM communication via mmap'ed memory, in my case I was working on using the DSP for rgb to yuv conversion. Another big gotcha to look out for is 64k boundaries. The DSP (at least in the 770) just can't naturally deal with object bigger than 64k, so you will get very bizarre results if you run into this limitation. Isn't it more a limitation of a free dsp toolchain? I have seen a pdf where OMAP1710 was mentioned to have c55x rev 3.0 core which does not have this limitation: http://www.ocpip.org/japanese/news/presentations/Japanese_JapanTI.pdf Also when looking for various DSP related information, I found Texas Instruments public ftp with the following interesting directory: ftp://ftp.ti.com/pub/cs/v275/ It looks like a linux c55x dsp toolchain with a slightly updated version, and what is more interesting, it lists OMAP1710 as one of the supported targets. I have also read about a rather scary thing such as silicon bugs :) Looks like silicon bugs are a lot more common in DSP than the bugs in general purpuse cores. My guess is that TI is solving this problem by releasing toolchains which are able to avoid generating problematic sequences of code. In this case having a compiler that is aware of the target core (OMAP1710 and OMAP2420) would be a really nice thing to have. If a more recent toolchain proves to be useful, maybe it would make sense asking TI to include it into a free linux dsp tools package? Or at least query about its status (whether it is ok to download and use that toolchain from ftp or they put it there by some mistake). Hope that this information might be useful for dsp hackers. ___ 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 fcntl.h
#include sys/ioctl.h
#include linux/fb.h
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: DSME code?
Jesse Guardiani wrote: I'd personally love to see DSME open sourced. 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 I'm not sure what exactly you want but blanking screen is possible via dsme somehow. At least there is dsmetest program ini initfs that communicates with dsme deamon and it can do it. Just run # chroot /mnt/initfs /usr/sbin/dsmetest to see the help. -d 2 is the one to turn display. You may probably use strace to see what it is writing to /tmp/dsmesock Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSME code?
Austin Che wrote:
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 fcntl.h
#include sys/ioctl.h
#include linux/fb.h
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.
--
Jesse Guardiani
Programmer/Sys Admin
[EMAIL PROTECTED]
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: DSP vs. ARM endianness and struct packing
Right, I've recompiled the arm side test so that it has a structure
with members that are the same size as those tested on the DSP. My
apologies for my earlier mistake.
What happens if you pack the structure as in
typedef struct __attribute__ ((packed)) endian_test_struct {
Thank you for the suggestion.
On the DSP this is not accepted by the compiler (there might be other
options, but really I'm trying to match the padding of structures
between the two processors, so this is fine as you'll see below). I'm
using the following struct on the ARM:
typedef struct endian_test_struct {
unsigned int iamulong1; // 32bit
unsigned short iamuint1; // 16bit
unsigned short iamuint2; // 16bit
unsigned int iamulong2; // 32bit
unsigned short iamuint3; // 16bit
unsigned int iamulong3; // 32bit
} endian_test_struct;
With no packing pragma we get this:
Byte #: Hex :
Byte 0: 78
Byte 1: 56
Byte 2: 34
Byte 3: 12
Byte 4: 34
Byte 5: 12
Byte 6: 34
Byte 7: 12
Byte 8: 78
Byte 9: 56
Byte 10: 34
Byte 11: 12
Byte 12: 34
Byte 13: 12
Byte 14: 0
Byte 15: 40
Byte 16: 78
Byte 17: 56
Byte 18: 34
Byte 19: 12
So the short has been padded into the start of a 32bit space. This is
the same as happens on the DSP, so I should be able to copy the
structure over and then fiddle with the endianness of its members.
With the packing pragma we get the following:
Byte #: Hex
Byte 0: 78
Byte 1: 56
Byte 2: 34
Byte 3: 12
Byte 4: 34
Byte 5: 12
Byte 6: 34
Byte 7: 12
Byte 8: 78
Byte 9: 56
Byte 10: 34
Byte 11: 12
Byte 12: 34
Byte 13: 12
Byte 14: 78
Byte 15: 56
Byte 16: 34
Byte 17: 12
Which as you suggest has removed the padding and produced a shorter struct.
Cheers,
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Porting fltk-app
Tapani Pälli wrote: ext Jørn Christensen wrote: Hi, Thanks for your answer, and sorry for my late answer, but I am a bit busy with my studies as well. Eero Tamminen wrote: Hi, ext Tapani Pälli wrote: I am trying to port an FLTK (www.fltk.org) application to N770/N800. I got FLTK compiled and the application as well, but when I run the application, it is not managed by Matchbox. That is, the program is not shown in the taskbar and the keyboard will not pop up. I have tried to hack FLTK according to the code snippets https://garage.maemo.org/snippet/detail.php?type=snippetid=3 and https://garage.maemo.org/snippet/detail.php?type=snippetid=4 but without luck. What do I need in order for Matchbox being aware of my program? The window is being managed by matchbox. Maemo input-methods (keyboard, hwr) use their own protocol to communicate directly with gtk-widgets. You have to implement this protocol in text-entry fltk-widgets. Basically it means sending an X to the input method window when the widget wants the input method to show itself. In the Maemo Gtk this happens when user taps to a widget. Maemo Input Method framework was just opened, so now other widget sets like Fltk or Qt can be fully ported to Maemo. The IM protocol source for widget - input method communication is here: https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-input-method-framework/src/ This is just the source, and searching google gives only sparse documentation for it. And none of how to make fltk-apps display the keyboard and receive inputs from it. Is there any real documentation for it? In order to get program shown in taskbar (which is a pager, not a component of window manager) you have to provide valid .desktop file. Instructions to do this is in maemo.org documentation. I found an example on a .desktop file and (basically) copied it. When I start the program, the notification says Launching ThinLinc (the program), but nothing happens. I also tried to make a service file - but with no luck. You have to copy .desktop file to /usr/share/applications/hildon directory. What version(s) of Maemo are you using? There used to be some issues with .desktop files not having _exactly_ correct syntax .. Well, I toyed a bit around with it and found out that the reason for the program not launching was that in my service-file, I had written com.cendio.thinlinc instead of com.nokia.thinlinc!!! Anyway - program launches fine now, but still no icon in the pager! Any advice? And oh, thanks for your help :-) ~Jørn ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
threaded applications on maemo
Hi there to the list, I was wondering what is the suggested practice to develop threaded applications which are maemo-friendly. I'm asking this because I've run into big troubles when trying to port an application which makes use of GThreads (which I assume should work on maemo, being maemo very glib-centric) on N800 latest firmware. The problem is that if I run something like (after calling g_thread_init() of course): something = g_thread_create((GThreadFunc)core_socket_up, user_data, FALSE, error); I've checked error which is NULL, but core_socket_up never get called (shotgun debugging with g_debug). The interesting part is that the application gracefully exits without any errors (it would be much better a segfault!) so giving me no clue about what is going on. So my question is: is the threading system known to work in a _RELIABLE_ way? Is it thoroughly tested? And more important, have you any clue on what could be the problem??? Cheers, Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
