Active Topics

 



Notices


Reply
Thread Tools
Dave999's Avatar
Posts: 6,806 | Thanked: 8,266 times | Joined on Oct 2009 @ Moon! It's not the East or the West side... it's the Dark Side
#681
The goal was to kickstart this thread. Mission accomplished!
__________________
Do something for the climate today! Anything!

I don't trust poeple without a Nokia n900...I'm also supporting Apple 2016 or until Jolla fully refund or ship the jPad to all backers and supports!

"waited over a year for no tablet and then the same again for potential refund? inspires confidence!"
 

The Following 4 Users Say Thank You to Dave999 For This Useful Post:
Community Council | Posts: 4,425 | Thanked: 11,043 times | Joined on May 2012 @ Southerrn Finland
#682
Qualcomm is the best-supported SOC for mobile devices, having tons of nice features and hence bering used in most of the top-line mobile devices.

However there are some downsides which I consider real dealbreakeres, and that is their baseband integration scheme.

The first thing you need to remember is that Qualcomm as a comapny is offshoot of the US military industry; it was first established to capitalize on communication and signals research done in the forces. The company still maintains close relationship with the government agencies and there is no doubt it includes some undesirable US-mandated features in their proprietary closed software and hardware.

This leads directly to the second point; it is impossible to use any communications features of a Qualcomm-SOC service without including in your kernel space closed binaries which have access to all of your memory and can do anything they like with the communication HW.... I believe this is somewhat undesirable

The situation here is exactly analoguous to Intel AMT coprocessor; The baseband processor in a Qualcomm SOC can interrupt and examine anything running on the main OM processor

Now as pointed out before, the only solution to this is to use separate baseband which acts like modem-only and has no direct access to the OM CPU. This solution is safe but it incurs some additional expenses and is not as power-efficient as an integrated solution.
 

The Following 10 Users Say Thank You to juiceme For This Useful Post:
Feathers McGraw's Avatar
Posts: 639 | Thanked: 2,294 times | Joined on Jul 2014 @ UK
#683
Chen, is i.MX8 a realistic option, or is the hardware design way more complicated to the extent that it would pose a risk to the project?

Asking because I'd happily accept a device that is slower but can run a mainline kernel without blobs that tie it to a specific version. Having a separate baseband appeals too. I'd probably pay more for this.

Having said that, I'd settle for a "mostly free" qwerty slider - that's infinitely better than no qwerty slider!
 

The Following 5 Users Say Thank You to Feathers McGraw For This Useful Post:
Posts: 76 | Thanked: 313 times | Joined on Jul 2012 @ Finland
#684
Originally Posted by jukk View Post
That would only be possible with the i.MX6 or i.MX8 that Purism has chosen for its future phone. And that requires separate modem. Native Linux on ARM outside of the embedded space is hard mostly because of missing GPU support in the kernel (of course there are problems with various sensors as well).
Articles explaining some of these problems:
https://lwn.net/Articles/733837/
https://lwn.net/Articles/733463/
Imagine that Android phones currently have 1 - 3 million lines of code in the kernel that is not released upstream. They have their own custom kernels! This situation is not reliable and the manufacturers know it.

This was the situation two years ago:
https://lwn.net/Articles/662147/

Unfortunately on the outside not much has changed yet. But if you listen to Greg K-H's latest talk on the subject it sounds a bit better:
https://youtu.be/RKadXpQLmPU?t=18m57s
(from around 19 minutes and forward the video has interesting details).

Kernel developer and maintainer Greg K-H and others have been actively "lobbing" manufacturers to begin upstreaming code. There is some hope for the future.
 

The Following 8 Users Say Thank You to jukk For This Useful Post:
Posts: 332 | Thanked: 1,751 times | Joined on Jul 2014
#685
Originally Posted by olf View Post
Please forget about "having native GNU/Lunix" as a core goal: This is what Purism is trying to achieve with 2 Million Dollars, two years time, awkward hardware etc.
Seconded, remaining focused on the goal here (create a beautiful modern keyboard slider device) is already tough enough without adding in extra compromises to get full mainline compatibility.

Remember that there exists a lot of people who want such an Android phone, and aren't really interested in mainline linux compatibility.

For people who want that kind of thing, there is neo900 and purism device projects which they may already be a part of further diluting the possible backers for this device.
__________________
SirenSong v0.5
Like my work? buy me a beer
 

The Following 11 Users Say Thank You to r0kk3rz For This Useful Post:
Posts: 132 | Thanked: 461 times | Joined on May 2010 @ Near Munich
#686
Regarding the high cost of OLED screens I just want to note that N9 display replacements, including controller and lightguide are currently selling for only 12.

See ebay.

And yes, these are in fact OLED screens, I ordered two from different sellers, and tested them (The controller board was glued off-center on the first one and it didn't fit into the case)
 

The Following 8 Users Say Thank You to Macros For This Useful Post:
Posts: 301 | Thanked: 1,382 times | Joined on Oct 2013 @ France
#687
Originally Posted by Feathers McGraw View Post
Chen, is i.MX8 a realistic option, or is the hardware design way more complicated to the extent that it would pose a risk to the project?
Not realistic without a huge company/dollars backing it.

* iMx8 is not ready yet. The first units will start to be available in the beginning of 2018, and seeing how the whole electronics industry is having a hard time to keep low factory lead time, it should need some time before them being easily available on small orders. Software support will probably take a lot of time too.

* Chen's project is possible because he wants to reuse an existing and validated PCB and "just" adding the keyboard and some tricks. Designing a new PCB is a lot of work, as can be seen with the time it takes to do it by the Neo900 project or by Purism (delivery in January 2019). You can see how chen's own Moto keyboard project has already been delayed to match the expected quality to see that the project has to be kept reasonable to have a chance to be fullfilled
 

The Following 8 Users Say Thank You to Zeta For This Useful Post:
olf's Avatar
Posts: 102 | Thanked: 379 times | Joined on Aug 2015
#688
@Chen, I am a little bit irritated about you regularly questioning basic premises, you reasonably set for this project months ago. Surely doing checks & balances is basically always a good thing, but re-evaluating fundamental cornerstones of this project again and again will lead (this project) nowhere.

From what I gathered in this thread months ago, your plan (and IMO the only feasible route for a project initially producing 3000 to 5000 devices, while hoping for more) is:
  1. Take an existing Qualcomm design as a basis.
  2. Create a new housing based on your Moto-Z keyboard, with a replaceable battery under the keyboard (to achieve a proper weight distribution, when the hardware keyboard is slid out).
  3. Adapt the existing PCB slightly to accommodate for the new keyboard connector and the relocated battery. Do absolutely avoid changing any high-frequency PCB traces, i.e. those connecting the SoC with the RAM, the analog WLAN circuitry, the analog Bluetooth circuitry and the mobile network circuitry. Keep all other changes to the existing PCB as minimal as possible, otherwise you will likely end up in months of hardware debugging, PCB simulations and the costs for a PCB design expert (or even worse with not properly working devices). We have seen that many times in the last 10 years, e.g. Openmoko GTA-01, -02, -03 and -04, Neo900, Pandora, Pyra etc. with only half of them succeeding after years of delays.
  4. Deliver the device with LineageOS preinstalled; this requires basing on a design which is already supported by LineageOS, otherwise you will be drafted into significant kernel adaptation work, which can easily stall this project for many months, too. Although some adaptation is likely to be necessary for the hardware keyboard, which is more than enough, IMO.
  5. Deliver the device with an unlocked boot-loader or (if regulatory requirements demand that) with an easily unlockable boot-loader (from within Android/LineageOS, e.g. as in Xperia X's latest OS release).
  6. Negotiate and settle a SailfishOS option with Jolla, before starting the crowdfunding campaign for the device; again low-level software adaptations are required for this, but having an Android-kernel from LineageOS supporting your device will ensure that all pieces are already there, they "just" need to be integrated into the "Android-kernel" used by Jolla (taking weeks to months). Hence choosing a design as a basis, which is somewhat similar to the Xperia X (i.e. Qualcomm Snapdragon 65x SoC, maybe also some of the peripheral chips, e.g. Bluetooth etc.) will reduce this adaptation work a lot.

The only other option to deviate from the base design, which does not require tremendous efforts, if carried out carefully, is the display: Please do not pick any higher resolution than "FullHD" (i.e. 1920x1080/1200 pixels), rather go for a 1280x720 px display or something slightly higher (e.g. 1440x900, 1600x1080). Very high resolution displays have significant drawbacks, e.g. (in descending order) power consumption, drawing speed (2D and 3D, due to many more pixels need to be drawn), maximal brightness, longevity etc.
Side note: A matte ("non-glaring") display (option) would be nice (I personally prefer them a lot), but requires a non-HighRes display (i.e. 1280x720 on 5,5" to 6", at most 1440x900 on a 6" to 6,5" screen), as the grainyness of the matte surface interferes with the extremely tiny pixels of HighRes displays, leading to an "unsharp" visual impression.
 

The Following 12 Users Say Thank You to olf For This Useful Post:
Posts: 332 | Thanked: 1,751 times | Joined on Jul 2014
#689
Chill olf, Chen isn't an idiot and knows the costs of developing a custom PCB.

You also seem to be misunderstanding exactly how the device adaptation process goes, generally speaking the OEM will give you an android aosp/caf adaptation which wouldn't be so bad building LineageOS from.

Also on the Sailfish OS porting side, the problem is the design of android doesn't have an 'android-kernel' and instead tends uses userspace driver blobs. As before I warned against being too similar to the Xperia X due to poor kernel support for some of its devices, particularly the Wifi+Bluetooth+FM chip. So no, just because something is well supported by Lineage OS doesn't mean all the pieces are there at all.
__________________
SirenSong v0.5
Like my work? buy me a beer
 

The Following 12 Users Say Thank You to r0kk3rz For This Useful Post:
olf's Avatar
Posts: 102 | Thanked: 379 times | Joined on Aug 2015
#690
Originally Posted by r0kk3rz View Post
Chill olf, [...]
@r0kk3rz, yes I do feel confused and a bit worried about a couple of continuously recurring points in this discussion thread. Maybe using "irritated" with all its possible connotations startled you, but Chen posted hardware specifications 2017-07-28 and a couple of more details in the following days, so everything seemed to be nicely set back then. But in the four months since then, all these premises were questioned again and again; by others, but also by Chen himself (at least this is how I interpreted his questions posted here). Maybe I misinterpreted the aim of these questions, but they clearly contradict the cornerstones of this project as set in late July / early August 2017.
But actually I would prefer @Chen to express, if these original plans still hold true or if they are reevaluated (or if his questions / considerations are solely addressing "future devices", as he once stated).

Originally Posted by r0kk3rz View Post
[...], Chen isn't an idiot and knows the costs of developing a custom PCB.
By no means I would consider him being an "idiot", actually many aspects of his statements and efforts made me trust him a lot, which rather contributes to my current confusion. And maybe I emphasised the aspect of PCB changes too much.
What I wanted to clearly get across was, "Please keep all changes as minimal as possible, as many have underestimated the delays and costs they cause in the past, and a couple of prospective projects died due to this."

Originally Posted by r0kk3rz View Post
You also seem to be misunderstanding exactly how the device adaptation process goes, generally speaking the OEM will give you an android aosp/caf adaptation which wouldn't be so bad building LineageOS from.
Well, I know. Actually "wouldn't be so bad" is a nice way to put it, which may still bear significant pitfalls in contrast to having something working in the first place. But discussing this is irrelevant, if the hardware is still set (and yes, I shouldn't have brought this detail up yesterday).

Originally Posted by r0kk3rz View Post
Also on the Sailfish OS porting side, the problem is the design of android doesn't have an 'android-kernel' and instead tends uses userspace driver blobs.
Look, these are technicalities I tried to avoid, when calling the whole non-mainstream kernel and (partially user-space blob) drivers (i.e. the whole low-level software stack) "Android-kernel" (explicitly in quotation marks): This whole foo has to be adapted to be used by libhybris and Mer / SailfishOS, which takes significant time and efforts.

Originally Posted by r0kk3rz View Post
As before I warned against being too similar to the Xperia X due to poor kernel support for some of its devices, particularly the Wifi+Bluetooth+FM chip.
Oh, I missed that: Thanks for pointing out, that a similar Wifi+Bluetooth+FM chip is rather a disadvantage.
OTOH, SailfishOS supports that already (although with some issues / lacking features), while support for alternative peripheral chips has to be integrated first. So this also is a question of time-to-market and costs (and again irrelevant, if already chosen).

Originally Posted by r0kk3rz View Post
So no, just because something is well supported by Lineage OS doesn't mean all the pieces are there at all.
Well, on this point I disagree even on the technical side of things: While I deliberately put the "just" in quotation marks, a hardware well supported by LineageOS will provide many pieces of low-level software to be reusable (some needing to be adapted) without legal and business interactions to get access to and the right to distribute the BSP (board support package) etc. This is a big plus in terms of time and costs involved, IMO, if similar kernel versions for SailfishOS and Android are available. Maybe the Android 6 based release with a better fitting "Android-kernel" version (for SailfishOS) was still published under the CyanogenMod label.
 

The Following 11 Users Say Thank You to olf For This Useful Post:
Reply

Tags
n950 revival, q-device, qwerty keyboard, sailfishos, sailingchen

Thread Tools

 
Forum Jump


All times are GMT. The time now is 23:22.