BECOMEROOT
Thank you very much to the developers and maintainers of the pages: http://mg.pov.lt/770 and http://eko.one.pl/maemo because they had a folder for MAEMO distributions (that is ITOS 2006) with the package BECOMEROOT in it, and now they had ERASED it completely. Nevertheless, http://mg.pov.lt/770 has kept a folder called obsolete with a package becomeroot in it, but it doesn't work. It's great that they help us so much. I've just reflashed my 770 and won't be able to easily become root again unless I buy an N800 and install BORA on it. I wish I had downloaded and saved the deb packages. Now I'm fucked. Fucking thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
HI,
Long time ago I tried to investigated the problem of replacing pixel's
colors. So, I faced with that problem again. But the problem is in the
result of getpixel() method. I use the similar one:
Uint32 getpixel(SDL_Surface *surface, int x, int y)
{
int bpp = surface-format-BytesPerPixel;
/* Here p is the address to the pixel we want to retrieve */
Uint8 *p = (Uint8 *)surface-pixels + y * surface-pitch + x * bpp;
switch(bpp) {
case 1:
return *p;
case 2:
return *(Uint16 *)p;
case 3:
if(SDL_BYTEORDER == SDL_BIG_ENDIAN)
return p[0] 16 | p[1] 8 | p[2];
else
return p[0] | p[1] 8 | p[2] 16;
case 4:
return *(Uint32 *)p;
default:
return 0; /* shouldn't happen, but avoids warnings */
}
}
In case of Nokia that method returns *(Uint16 *)p. But instead of 6
hexadecimals it returns only 4. For example, for white color it returns
instead of F. The same, for the rest of colors.
Any idea why?
On Mon, Feb 12, 2007 at 11:35 AM, Tapani Pälli [EMAIL PROTECTED]
wrote:
ext Michael Stepanov wrote:
Thanks for your answer, Tarani.
On 2/12/07, *Tapani Pälli* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
ext Michael Stepanov wrote:
Well, there is a open source system for home automation -
Plutohome
(www.plutohome.com http://www.plutohome.com
http://www.plutohome.com http://www.plutohome.com). This
system can use
Nokia770/800 as a control panel - Orbiter. The Orbiter is based on
SDL. So, after some hack it started work on Nokia
(os2005/os2006) but
there is a problem. Icons on the Orbiter should change their color
according to some events.
Are you missing icon 'highlight' effect when mouse is moved on top
of
icon? Please specify exactly what the 'some events' are.
The color of icon should be changed according to status of real device
which represented by this icon. For example, there is a lighting
switch and its icon. If switch is ON icon should be yellow, otherwise
it should be black. But in real device icon every time is pink. I
suspect that something wrong with pixels coloring using SDL. There is
a method
Ah ok, pink might be colorkey for 1-bit transparency and shouldn't be
displayed.
OrbiterRenderer_SDL::ReplaceColorInRectangle in the
OrbiterRenderer_SDL.cpp which changes colors of icons. Maybe SDL for
nokia 770 uses different color format for pixels?
Yep, you could try a simple hack to find out wheter bug is here by
replacing putpixel call in loop to paint only red :
SDLGraphic::putpixel(m_pScreenImage,i + x, j + y, SDL_MapRGB(PF, 255, 0,
0); ... it seems algorithm is checking wheter destination color differs
from source enough and if so it paints. However I don't see anything
wrong in getpixel or putpixel, they should OK.
Initially they are pink. Using SDL functionality their color can
be
changed. It works fine for Debian but it didn't work for Nokia
(either
scratchbox emulator or real device). All icons are pink every
time.
I'm not developer. I'm integrator. So, it's difficult for me to
understand where is the problem. Have a look attached files.
Maybe you
can help me.
I couldn't spot bugs in the code you sent, maybe OrbiterLogic has
some
calls to renderer to change icon colors?. One thing which should be
changed in renderer class is the colordepth used for surfaces.
Right now
it seems to be hardcoded to certain places as 32. Code should read
the
correct depth using SDL_GetVideoInfo and make sure all the newly
created
surfaces use the same depth to avoid amount of needed conversions.
Thanks, I check it.
Thanks in advanced.
On 2/9/07, * [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]*
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
Hello,
Could you be more specific what are you trying todo and how?
Are you
going through pixelvalues and accessing them? See
surface-format-BytesPerPixel. SDL_GetRGB and SDL_MapRGB
should work
allright.
// Tapani
--- 8 -
// T
--
Cheers,
Michael
// Tapani
--
Cheers,
Michael
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: BECOMEROOT
2008/4/15, Fred [EMAIL PROTECTED]: There is no need to be so upset ... Yes, there is. Definitely. You can still do it the old way : - Switch to RD mode (with the linux flasher - edit the gainroot shell script Yeah, sure, why not? You're done ;) Yes, I'm done... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
Michael Stepanov wrote: In case of Nokia that method returns *(Uint16 *)p. But instead of 6 hexadecimals it returns only 4. For example, for white color it returns instead of F. The same, for the rest of colors. Any idea why? Some typo in your mail? Uint16 is 16 bit value, you really can't fit more than there :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
On Tue, Apr 15, 2008 at 3:30 PM, Frantisek Dufka [EMAIL PROTECTED] wrote: Michael Stepanov wrote: In case of Nokia that method returns *(Uint16 *)p. But instead of 6 hexadecimals it returns only 4. For example, for white color it returns instead of F. The same, for the rest of colors. Any idea why? Some typo in your mail? Uint16 is 16 bit value, you really can't fit more than there :-) You're right. I'm not C++ developer. Just try to port some application to maemo :) So, how in that situation I can get correct color? -- Cheers, Michael ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: BECOMEROOT
On Tue 15 Apr 2008 15:28, sebastian maemo [EMAIL PROTECTED] writes: 2008/4/15, Fred [EMAIL PROTECTED]: There is no need to be so upset ... Yes, there is. Definitely. You can still do it the old way : - Switch to RD mode (with the linux flasher - edit the gainroot shell script Yeah, sure, why not? You're done ;) Yes, I'm done... rootsh works also on itos 2006. kvg... i.e. search google with 'rootsh maemo' Tomi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
Michael Stepanov wrote: So, how in that situation I can get correct color? It is already correct. The color format is RGB565. What 'correct' means to you in this context? If you need the value in different format you need to convert it. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Nokia SDL color format for pixels
Michael Stepanov wrote: int bpp = surface-format-BytesPerPixel; You can check also other fields of SDL_PixelFormat structure to get R,G,B color components. Interesting field names are Uint8 Rloss; Uint8 Gloss; Uint8 Bloss; Uint8 Rshift; Uint8 Gshift; Uint8 Bshift; Uint32 Rmask; Uint32 Gmask; Uint32 Bmask; Or you can use SDL_GetRGB(Uint32 pixel, SDL_PixelFormat *fmt, Uint8 *r, Uint8 *g, Uint8 *b) function which will probably do the dirty bit shifting and masking work for you. http://www.google.com/search?q=SDL_GetRGB ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
hildon_color_button custom colors issue
Hi, while porting Xournal to Maemo I decided to give it as much hildonization is possible. Base xournal uses only a bunch of predefined colors (something like 9 or 10 colors). I decided to use the hildon_color_button widget to give the user a much wide choice of colors. I get the GdkColor from the color button and have to convert it in RGBA because Xournal only works with those values (passing fill-color-rgba to the canvas items). It does this, I think, for being able to make a highlighter tool available in different colors (by making use of the alpha channel). anyway, I convert the GdkColor to RGBA using the macro: GdkColor *color; // read from the hildon_color widget guint alpha = 0xFF; // no transparency guint rgba = GNOME_CANVAS_COLOR_A (color-red, color-green, color-blue, alpha) and then use it wherever it is needed. This works for the predefined colors in the color chooser dialog. But if I choose my own custom color it does not. If I use the GdkColor as is (thus passing fill-color-gdk to the canvas items), it works, but I can't use the alpha channel (can I ?). If I convert this custom color to RGBA with the given macro, it paints in a totally different color. Is this some issue with the colormap ? Is GNOME_CANVAS_COLOR_A not good for this ? Any other hints ? -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: BECOMEROOT
Good afternoon! On Tue, Apr 15, 2008 at 01:10:41PM +0100, sebastian maemo wrote: Thank you very much to the developers and maintainers of the pages: http://mg.pov.lt/770 That would be me. because they had a folder for MAEMO distributions (that is ITOS 2006) with the package BECOMEROOT in it, and now they had ERASED it completely. Not quite -- I moved becomeroot 0.1 deb to a different folder (obsolete) because there was a new version of becomeroot out there (0.2) that had quite different behaviour, and I wanted to avoid confusion. (I don't think I ever removed a package completely. Maybe once, when the package in question was so broken that it could brick your device.) Nevertheless, http://mg.pov.lt/770 has kept a folder called obsolete with a package becomeroot in it, but it doesn't work. Please define doesn't work. I had used it successfully on my 770. Note that becomeroot 0.1 allowed you to do sudo su to get a root shell, while becomeroot 0.2 was changed and had you use sudo gainroot instead. I don't know what precisely you expected, but if you ever installed becomeroot form my repo, you should be able to sudo su. It's great that they help us so much. I'm glad you appreciate it. I've just reflashed my 770 and won't be able to easily become root again unless I buy an N800 and install BORA on it. There are many ways of getting root that are a bit simpler than that. (Although I would recommend getting a N800 or N810, as the hardware is nicer than the 770.) I wish I had downloaded and saved the deb packages. Now I'm fucked. Fucking thanks. Have a nice day! Marius Gedminas -- Be yourself. Especially, do not feign respect for technical incompetance. signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildon_color_button custom colors issue
I reply to myself. I was testing the app running it from a remote SSH (root) and not from the user's Menu. It works. Thanks anyway. Aniello On Tue, Apr 15, 2008 at 5:50 PM, Aniello Del Sorbo [EMAIL PROTECTED] wrote: Hi, while porting Xournal to Maemo I decided to give it as much hildonization is possible. Base xournal uses only a bunch of predefined colors (something like 9 or 10 colors). I decided to use the hildon_color_button widget to give the user a much wide choice of colors. I get the GdkColor from the color button and have to convert it in RGBA because Xournal only works with those values (passing fill-color-rgba to the canvas items). It does this, I think, for being able to make a highlighter tool available in different colors (by making use of the alpha channel). anyway, I convert the GdkColor to RGBA using the macro: GdkColor *color; // read from the hildon_color widget guint alpha = 0xFF; // no transparency guint rgba = GNOME_CANVAS_COLOR_A (color-red, color-green, color-blue, alpha) and then use it wherever it is needed. This works for the predefined colors in the color chooser dialog. But if I choose my own custom color it does not. If I use the GdkColor as is (thus passing fill-color-gdk to the canvas items), it works, but I can't use the alpha channel (can I ?). If I convert this custom color to RGBA with the given macro, it paints in a totally different color. Is this some issue with the colormap ? Is GNOME_CANVAS_COLOR_A not good for this ? Any other hints ? -- anidel -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo icons
I'm having the same problem with icon sizes, altho I'm using Pypackager. It seems to me there are at least four different places where an application icon appears, and in different sizes. (0) In the Application Manager - Show installed applications (40?) (1) In the Task Navigator (64?) (2) In the Application Switcher - most recently launched (26?) (3) In the Application Switcher - all running (40?) There are also at least four different places where icons themselves are placed when installed: /usr/share/icons/hicolor/26x26/hildon/usr/share/icons/hicolor/40x40/hildon/usr/share/icons/hicolor/scalable/hildon/usr/share/pixmaps The sizes of the 1st two are clear, but the others, not so much. In addition when using Pypackager there's an enty area for an Icon URL that lets you select a location in the file system. Can anyone explain the mapping between where the icons appear when the files are placed. And what sizes they are supposed to be? While I can get an icon to appear in the Task Navigator it's not the large one that I want. I can't get the right one to appear in the Application Manager either, and I get the default cubes in both Application Switcher. And I've read the the Maemo Tutorial and I can't figure it out from that. Thanks for any help. -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo icons
I'm having the same problem with icon sizes, altho I'm using Pypackager. It seems to me there are at least four different places where an application icon appears, and in different sizes. (0) In the Application Manager - Show installed applications (40?) (1) In the Task Navigator (64?) (2) In the Application Switcher - most recently launched (26?) (3) In the Application Switcher - all running (40?) There are also at least four different places where icons themselves are placed when installed: /usr/share/icons/hicolor/26x26/hildon/usr/share/icons/hicolor/40x40/hildon/usr/share/icons/hicolor/scalable/hildon/usr/share/pixmaps The sizes of the 1st two are clear, but the others, not so much. In addition when using Pypackager there's an enty area for an Icon URL that lets you select a location in the file system. Can anyone explain the mapping between where the icons appear when the files are placed. And what sizes they are supposed to be? While I can get an icon to appear in the Task Navigator it's not the large one that I want. I can't get the right one to appear in the Application Manager either, and I get the default cubes in both Application Switcher. And I've read the the Maemo Tutorial and I can't figure it out from that. Thanks for any help. -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: BECOMEROOT
2008/4/15, Frantisek Dufka [EMAIL PROTECTED]: It is still here http://eko.one.pl/maemo/dists/bora/user/binary-armel/becomeroot_0.1-2_armel.deband since it is simple shell script it should work on any system including OS2006, just install/click the deb directly, do not add Bora repository. Again, I must thank Frantisek for his help. He also helped me a lot when I was truly upset for not being able to install a root file system in the MMC. At that time, I didn't even know how to edit a file with vim... With his kind help, I finally succeeded, and then wrote a howto where I described all the steps I followed, with his guidance. Just to be helpful and grateful to the linux maemo community. I must admit that it was really hard, but I learned a lot I didn't know about linux systems and basic administration. But it's too much, right? I cannot accept that a deb package in a bora folder is going to be useful for a mistral distribution. It's good that (as you kindly warn me) it's a simple shell script and should work anyway... but I don't want to know it. For me it's too much... I don't want to check the contents of deb packages to see whether they are going to work on my 770 or not. Bora means N800 and that's it. I'm supposed not to even touch that folder. I'm not ashamed to be a linux ignorant, by the way. When I bought my 770 nobody warned me that if I wasn't a linux hacker then my little device would only be useful to surf the web (slowly and without Flash and Java features). I can install lots of applications in my cellphone (also a Nokia). But I can install only a few applications in the 770, unless I do a (non-trivial) trick to install them on the MMC. To learn that trick was really hard. And Frantisek helped me a lot with that. Now, the package I need is gone to another folder. A folder I'm supposed not to check because I'm using mistral distribution... That's fucking nonsense. There's a chaos in deb packages maintaining and distribution... It's obviously Nokia's fault... Or maybe it's my fault because I've bought a Nokia 770 without getting first a master degree in computer science... (is that what Marius means in his PD??). I think that I'll be able to get my 770 booting again from MMC, but this kind of things should never happen. At least to a simple end user... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Q: Where submit patches?
Is this an appropriate venue to propose patches? I have a small change to /etc/udhcpc/udhcpc.script which allows it to connect to more sites. -- Allen Brown [EMAIL PROTECTED] http://brown.armoredpenguin.com/~abrown/ Those who do not understand Unix are condemned to reinvent it, poorly. --- Henry Spencer ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
