Page 1 of 2 12 LastLast
Results 1 to 20 of 27
Like Tree10Likes
  1.    #1  
    Is this

    Devices/PalmPre/InstallGuide €“ SHR

    project maybe useful somehow to allow to "port" luneos on pre/pre2/veer/pre3 ? (given that there's a build of shr for both pre and pre2 able to boot, a version of uboot, instructions on how to keep the proprietary FIRMWARE from webos to enhable the modules etc ? )
  2. #2  
    Quote Originally Posted by mazzinia View Post
    Is this

    Devices/PalmPre/InstallGuide – SHR

    project maybe useful somehow to allow to "port" luneos on pre/pre2/veer/pre3 ? (given that there's a build of shr for both pre and pre2 able to boot, a version of uboot, instructions on how to keep the proprietary FIRMWARE from webos to enhable the modules etc ? )
    The amount of RAM in the Pre and Pre 2 wouldn't allow LuneOS to run properly. The main SHR developers are also part of the WebOS Ports team SHR is not actively developed anymore anyway. Also LuneOS is using a way newer 3.x kernel and not the 2.x kernel that Palm/HP made available and is part of SHR as well?
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  3.    #3  
    That's why I titled it "supid question" :P (would also a pre3 be too low on ram ?)

    Out of curiosity, what are the advantages of using a 3.x kernel vs a 2.x (for phones) ?
  4. #4  
    Quote Originally Posted by mazzinia View Post
    That's why I titled it "supid question" :P (would also a pre3 be too low on ram ?)

    Out of curiosity, what are the advantages of using a 3.x kernel vs a 2.x (for phones) ?
    The OMAP based Pre (2) was actually handling memory better compared to the Qualcomm based Pre 3/Veer due to the fact that on the Pre 3 and Veer were using RAM for the modem as well, where the OMAP based phones didn't. So the Pre 3 is also not a very likely candidate. The 1GB on the TP is already on the tight side.

    The 3.x kernel has some benefits (I'm not a kernel expert so I couldn't give the specifics).
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  5.    #5  
    I see, thanks.

    It's a pity that it's not possible to build around qnx/neutrino... has a smaller footprint than linux/android
  6. #6  
    Quote Originally Posted by mazzinia View Post
    I see, thanks.

    It's a pity that it's not possible to build around qnx/neutrino... has a smaller footprint than linux/android
    Actually BB10 uses WebKit as well which is the biggest memory consumer. When you check the specs of the BB10 phones, you'll see that they all have at least 1.5GB of RAM! Most have 2GB or more!
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
    Remy X likes this.
  7.    #7  
    Yep, I know that BB uses qnx.. but didn't know that webkit used so much ram. Anyway even if an older version, also webos 2.x uses webkit and "survives" with 512mb ( I know that 256mb more would have been better, at least ).
    Should I suppose that the more recent evolutions of webkit are more memory hogs ?
  8. #8  
    Quote Originally Posted by mazzinia View Post
    Yep, I know that BB uses qnx.. but didn't know that webkit used so much ram. Anyway even if an older version, also webos 2.x uses webkit and "survives" with 512mb ( I know that 256mb more would have been better, at least ).
    Should I suppose that the more recent evolutions of webkit are more memory hogs ?
    Yes and Palm/HP were using a highly customized version of WebKit (4.6) which was very difficult to upgrade. We're using a very lightly modified version of WebKit2 (included in QT 5.3/5.4) which has a lot more features, is easier to upgrade, but will use more RAM.

    Also the legacy webOS BrowserServer/BrowserAdapter model is gone with QT5/WebKit2 which leads to a memory increase as well.
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  9.    #9  
    Translation : hp/palm saved the cost of adding ram by spending money on the programming team (customizations), a road that was likely sensible as total costs back in 2009/2010 considering the prices of modules , and is not sensible now due to cheaper and bigger modules.
  10. #10  
    Quote Originally Posted by mazzinia View Post
    Translation : hp/palm saved the cost of adding ram by spending money on the programming team (customizations), a road that was likely sensible as total costs back in 2009/2010 considering the prices of modules , and is not sensible now due to cheaper and bigger modules.
    Yup and also the fact that Ports doesn't have the 100's of devs that HP/Palm had makes it more feasible to use "vanilla" stuff instead of highly customized and labor intensive customizations. RAM was cheap even in the days, not putting it in was just being "cheap".
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
    Grabber5.0 likes this.
  11.    #11  
    Obviously, but I suspect Rim and Google are not investing their battalions of programmers into this specific task, too.
    Ram was cheap even in the days, but surely less cheap than now... and trust me, they overall spent less for their 100 programmers effort, than the extra 0.xusd/unit or such to add more ram. Yes, in a way was being cheap. At the same time it was a better job than what a lot of companies do by relying on the increasingly more powerful hd / cheaper bigger ram sticks and bigger hard disks, from a purely technical point of view of optimizing resources

    ps

    the "now" before was not referred to Ports, but to Google / Rim / Apple , the 3 actors ( I suppose ) mainly behind webkit usage
    Remy X likes this.
  12. #12  
    Yeah, WebKit2 is definitely a pig in terms of memory use, and what's worse, Chrome on XP actually leaks memory in the kernel space, so you end up with a 5GB pagefile and no running process to "claim" the memory leak. And then, on the flip side, at times, closing Chrome will cause XP to bluescreen, when it starts de-allocating memory that's in use by the kernel. I'm guessing that it has something to do with graphics-related routines, but the BSoD problem has been around for two and half years with no effort on their part to solve it.
    ...
  13.    #13  
    Well, nor Chrome nor Firefox nor Opera have a really good memory management (windows, but I doubt things change if changing os), and it becomes evident with a less "standard" usage ( I have always around 10 windows, and a total of over 100 Tabs open)
  14. #14  
    So not a suggestion, proposal or request, but what would be needed for:

    a) A port of LuneOS
    b) Some kind of LunaCE type upgrade for webOS 2.2.4

    and of those requirements, what already exists?
  15. #15  
    Quote Originally Posted by Preemptive View Post
    So not a suggestion, proposal or request, but what would be needed for:

    a) A port of LuneOS
    b) Some kind of LunaCE type upgrade for webOS 2.2.4

    and of those requirements, what already exists?
    I've talked to dkirker about it.

    LunaCE for legacy phones would take a lot of reverse-engineering, because of the differenced between the unreleased LunaSysMgr of 2.x and the largely Open Sourced 3.x. It is possible to start over and use the 3.x LunaSysMgr and try to go back and build the lost functionality, but you'd still have to deal with some undocumented "binary blobs" like hidd... which is the "human interface device daemon", a kernel module that controls input, especially the touchscreen's gesture area. He said that the guy who worked on that had become really burned out while at HP/Palm, and is unlikely to ever want to help anyone with it.

    LuneOS for Qualcomm phones like the Pre3 and the Veer would be a challenge IMHO, considering 300-some MB of RAM that are available to the OS, versus 1GB in modern phones that LuneOS is geared for.

    So it's not fun either way. We can hope, we can raise funds, but there's no "easy button".
    ...
    Preemptive likes this.
  16.    #16  
    slightly deviating from the topic, but I know of some people that did enough crazy mods ( removing a bga cpu and replacing it with another ) so, just as a speculative exercise, I wonder if the ram module is pin to pin compatible with a newer 1gb or such.

    Not that I think there would be a lot that would consider to test, if if if, but a partially broken unit could always be a reasonable sacrifice / test subject :P
    Remy X likes this.
  17. #17  
    Quote Originally Posted by Remy X View Post
    So it's not fun either way.
    Hmmm... interesting about the gesture area - I'd assumed that it was the same code for the whole surface regardless of whether there was a display underneath.

    I wasn't expecting this to be easy, but I thought there might be suggestions about modifying 2.2.4 or finding Android drivers for the phone. I forget how far phones are using specialised components and customised code.

    I wonder if (in theory only) decompiling & reverse engineering is possible. Again, I'm not expecting anyone to do any of these things - the first stumbling block would be the sheer amount of work required.

    In general, I'm in favour of using newer hardware rather than looking backward, but I'm curious because the limited number of H/W keyboard models aside, there are obviously no other phones out there with gesture areas...

    It may be easier than ever to build hardware and costs may well fall in the coming year due to excess capacity resulting from falling sales, but even so, it's very unlikely that there are enough people interested to raise the kind of money needed for a 'community phone'.
  18. #18  
    Quote Originally Posted by Preemptive View Post
    Hmmm... interesting about the gesture area - I'd assumed that it was the same code for the whole surface regardless of whether there was a display underneath.
    You're correct... And the same kernel daemon does a lot of stuff in processing user input and makes the data available in a convenient format. But being a "black box" of compiled code, it has to be studied before it can be put to use or a replacement can be built. It's just one of the examples of purpose-built code that we don't have the source code for.

    I think it was that back/forward gestures are calculated by the daemon rather than handing raw driver data to LunaSysMgr, and that it had some interlocking behavior with the old LunaSysMgr, which would have to be re-implemented from scratch, and that's at least a week's work for someone who knows what to do. And the hurdles add up to the point that qualified devs here prefer smaller projects where they'd know that everything is straightforward and won't consume a lot of their free time while being perceived as unimportant.

    Nobody wants to touch the ugly stuff they won't get much thanks for fixing, when there are equally important things no-one has time for.

    Quote Originally Posted by Preemptive View Post
    I wasn't expecting this to be easy, but I thought there might be suggestions about modifying 2.2.4 or finding Android drivers for the phone. I forget how far phones are using specialised components and customised code.
    Yeah, we were lucky with the Touchpad in both, having the Android drivers, and in having an Open Source copy of LunaSysMgr to build LunaCE from.

    I think some of the drivers would have to be written from scratch, another difficult but unglamourous job. With the Touchpad, we had Qualcomm prototypes that ran Android, but with the phones, the only thing lemanho was able to obtain from Chinese sources was a couple of Veers with diagnostic firmware. The Android prototypes were likely reflashed to webOS before they made it out of the lab. But some of those newer components may have Android drivers for another device, so you're not that far off.

    Those Android drivers, however, may also require different firmware to be flashed onto those chips. There's a 100% chance of that being the case with the camera module, if it was used in another phone besides the Pre2/3

    Quote Originally Posted by Preemptive View Post
    I wonder if (in theory only) decompiling & reverse engineering is possible. Again, I'm not expecting anyone to do any of these things - the first stumbling block would be the sheer amount of work required.
    It's definitely possible, but it requires a specific skill set, so not every willing person is qualified, and not every qualified person has free time...

    Quote Originally Posted by Preemptive View Post
    In general, I'm in favour of using newer hardware rather than looking backward, but I'm curious because the limited number of H/W keyboard models aside, there are obviously no other phones out there with gesture areas...
    The Oppo Find5 has a "gesture area" that can be put to use, but it's a 5" slab phone with no LTE. So nobody wants to port to it. If i had a better paying job, i'd fund that project myself.

    Quote Originally Posted by Preemptive View Post
    It may be easier than ever to build hardware and costs may well fall in the coming year due to excess capacity resulting from falling sales, but even so, it's very unlikely that there are enough people interested to raise the kind of money needed for a 'community phone'.
    I tend to agree with you. With small production volumes, phones are likely to be $600 apiece, and the manufacturer would want to do a run of 3,000... so... while it's doable, there can never be an agreement among the community where everyone will be willing to pay that much for a phone they percieve as being either too big or too small... nitpicking comes with the pricepoint, and will likely poison the effort.

    I'm not being pessimistic, just looking at the difficulties first, because the positive aspects, well, we know them already
    Last edited by Remy X; 12/07/2014 at 02:42 PM.
    ...
  19. briest's Avatar
    Posts
    133 Posts
    Global Posts
    134 Global Posts
    #19  
    Quote Originally Posted by Preemptive View Post
    there are obviously no other phones out there with gesture areas...
    But most of Android phones nowadays have the "buttons" (Back, Home, ...) realized as capacitive touchscreen -- this space practically begs to be used for gestures instead.
    T5, Clié NZ90, Treo 650, Centro, Pre, Pre+, Pre 2, Pre 2, Pre2, Nexus7@LuneOS
    Preemptive likes this.
  20. #20  
    Quote Originally Posted by briest View Post
    But most of Android phones nowadays have the "buttons" (Back, Home, ...) realized as capacitive touchscreen -- this space practically begs to be used for gestures instead.
    Good point.

    Are these buttons permanently present? Do they vanish when using an app? What about a full screen video? I'm wondering about use of screen estate and aspect ratios. For example, taking 16:9 as a TV standard widescreen, most motion media will conform to this. So are modern mobile screens 16:9 or longer to allow for a control area? I'd expect a phone with physical buttons to have a 16:9 screen, but with software buttons, I'd guess the screen would either be bigger or the button panel would pop-up or vanish like an on-screen keyboard.

    Yes, I am quite ignorant of other systems! ;-)

    A longer screen with permanent buttons would indeed make a good gesture area while retaining a standard ratio. It might even be possible to enhance the area with tapable buttons (e.g. player controls for a video) whilst retaining the functions of the standard swipe actions.
    Last edited by Preemptive; 12/08/2014 at 07:53 AM.
Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 7
    Last Post: 08/24/2011, 11:04 PM
  2. Legacy Apps Question
    By rburtz in forum HP TouchPad
    Replies: 6
    Last Post: 06/22/2011, 12:05 PM
  3. I have a stupid question...:)
    By Jason Black in forum Palm Pre and Pre Plus
    Replies: 8
    Last Post: 05/16/2010, 11:56 AM
  4. Stupid Treo or Stupid Me? contacts view preferences question
    By billybob in forum Palm OS Devices & Apps
    Replies: 3
    Last Post: 11/25/2004, 10:10 PM
  5. another stupid question
    By Firelord in forum Palm OS Devices & Apps
    Replies: 1
    Last Post: 04/30/2000, 10:00 PM

Posting Permissions