00:20.52 | *** join/#neo900 modem (~modem@fsf/member/modem) |
01:08.25 | *** join/#neo900 lobito (~lobito@190.177.221.93) |
02:00.33 | *** join/#neo900 Humpelstilzchen (erik@f054029110.adsl.alicedsl.de) |
02:46.22 | *** join/#neo900 wicket64 (~wicket@181.50.101.138) |
03:59.05 | *** join/#neo900 nicksydney (~quassel@1.077.dsl.syd.iprimus.net.au) |
06:32.54 | *** join/#neo900 jonsger (~Thunderbi@2a02:8070:791:2f00:5448:2eb1:10:6c24) |
06:37.43 | *** join/#neo900 tomeff (~tomeff@ip-89-176-75-234.net.upcbroadband.cz) |
06:49.22 | *** join/#neo900 delphi (ns-team@devbin/founder/trx) |
07:07.42 | *** join/#neo900 Kabouik (~quassel@178.251.81.127) |
07:45.13 | *** join/#neo900 PeperPots___ (sid1218@gateway/web/irccloud.com/x-bgcxoimhtiuvalge) |
08:49.47 | *** join/#neo900 Kabouik (~quassel@178.251.81.127) |
08:59.41 | *** join/#neo900 stefek99 (sid41457@gateway/web/irccloud.com/x-bbjdipcsnkwktnwg) |
09:01.32 | *** join/#neo900 mzki (~koza@89-72-165-101.dynamic.chello.pl) |
09:50.44 | *** join/#neo900 XDS2010 (sid1218@gateway/web/irccloud.com/x-enryigmvleljgijs) |
10:13.55 | *** join/#neo900 Kabouik (~quassel@178.251.81.127) |
10:16.37 | *** join/#neo900 SylvieLorxu (~TheLastPr@dhcp-077-251-165-191.chello.nl) |
11:19.20 | *** join/#neo900 arossdotme-planb (~zxy@79-69-192-143.dynamic.dsl.as9105.com) |
11:19.58 | *** join/#neo900 l_bratch (~l_bratch@212.9.8.20) |
12:02.55 | *** join/#neo900 sparetire_ (~sparetire@unaffiliated/sparetire) |
12:14.39 | *** join/#neo900 Kabouik (~quassel@178.251.81.127) |
12:32.54 | *** join/#neo900 vakkov (~vakkov@s3n104.brunel.ac.uk) |
12:54.36 | *** join/#neo900 merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
13:01.45 | *** join/#neo900 vakkov (~vakkov@s3n104.brunel.ac.uk) |
13:12.03 | *** join/#neo900 itbaron (~kvirc@a88-115-8-208.elisa-laajakaista.fi) |
13:31.23 | *** join/#neo900 jonsger (~Thunderbi@2a02:8070:791:2f00:5448:2eb1:10:6c24) |
13:37.59 | *** join/#neo900 brendafdez (~Brenda@unaffiliated/brendafdez) |
14:13.55 | *** join/#neo900 vakkov (~vakkov@ic-s221n18.brunel.ac.uk) |
15:23.35 | *** join/#neo900 tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) |
15:29.19 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
15:36.09 | *** join/#neo900 arcean (~arcean@nat1-3.finemedia.pl) |
16:33.38 | DocScrutinizer05 | email inquiry >> 2 Could you list which things will contain proprietary software/binary blobs?<< I honestly don't know if I'm able to explain to people that we don't even know which of the chips we use contain some contain any proprietary software. There's definitely some software in the 9-axis accelerometer, and afaik even Nokia's ALS has some software. The mixed signal programmable matrix chip SLG46721V (http://www.silego.com/buy/ |
16:33.40 | DocScrutinizer05 | index.php?main_page=product_info&cPath=56&products_id=323) evidently has some limited amount of software built in. --- What was the question? |
16:36.00 | DocScrutinizer05 | the CPU has some hardcoded 'proprietary' bootloader in ROM that's unknown detail. |
16:36.25 | DocScrutinizer05 | the PMIC probably also has some software inside |
16:37.21 | DocScrutinizer05 | the LCD controller possibly has some software |
16:38.05 | DocScrutinizer05 | the touchscreen controller evidently has a firmware |
16:40.35 | DocScrutinizer05 | of course WLAN BT WWAN have firmware, luckily we presuably can update these |
16:41.09 | DocScrutinizer05 | camera chip has some software I guess. Probably both of them |
16:42.06 | DocScrutinizer05 | bq24xxx and bq27xxx both have software for sure |
16:43.28 | DocScrutinizer05 | LP55321 probably has some software (microcode) to execute the LED pattern programs |
16:47.12 | DocScrutinizer05 | thinking of it I realize I can't tell where 'software' starts and 'configuration' ends. Is a matrix with efuses already software? Or a mask programmed ROM? Or a hardwired sequence of sequential (or parallel) operations of the logic blocks in a CPLD or ASIC or standard IC |
16:49.13 | edwin | if its hardwired I'd say its not software cause you can't change it |
16:49.48 | DocScrutinizer05 | I can't change either of the above mentioned, except maybe for the WLAN, WWAN, BT stuff |
16:49.53 | edwin | to be software I think it should be changable, and be able to run a Turing complete language |
16:50.14 | DocScrutinizer05 | how would I know what's inside a chip? |
16:50.40 | edwin | is there a way to know if it has a firmware update interface? |
16:50.53 | DocScrutinizer05 | hiw would I run a test for turing completeness against a chip like BQ27200? |
16:51.00 | DocScrutinizer05 | no |
16:51.03 | *** join/#neo900 modem (~modem@fsf/member/modem) |
16:51.43 | DocScrutinizer05 | if those chips have any such firmware update interface then it's not documented by the chip manufacturer |
16:53.16 | DocScrutinizer05 | some datasheets mention something like "don't write to registers 8 - 26 since that could destroy the chip" |
16:53.49 | DocScrutinizer05 | is that a hidden firmware update feature? I don't know |
16:53.49 | edwin | so presumably they are some undocumented fuses or config registers, but hmm even 1 bit can suffice to update the firmware no? |
16:55.55 | DocScrutinizer05 | I guess that question in that email is being asked without a clear idea what's the actual question |
16:56.45 | DocScrutinizer05 | just like "how many of that foods do contain genes?" |
16:57.44 | edwin | I think classifying the chips based on what you know about them is the best you can do: |
16:57.45 | edwin | <PROTECTED> |
16:57.45 | edwin | <PROTECTED> |
16:57.45 | edwin | <PROTECTED> |
16:57.45 | edwin | <PROTECTED> |
16:57.46 | edwin | <PROTECTED> |
16:57.47 | edwin | <PROTECTED> |
16:58.43 | DocScrutinizer05 | thanks, that makes sense. Yes |
16:59.08 | edwin | so for example AFAIK the raspberry Pi requires firmware to be uploaded for its GPU otherwise the thing won't even boot |
16:59.14 | edwin | that'd be #1 there |
16:59.29 | edwin | my Radeon GPU has a firmware obviously , and there is a way to update it |
16:59.38 | edwin | but it works with the factory firmware and has open source drivers |
16:59.44 | edwin | so that'd be #2 there |
17:00.11 | DocScrutinizer05 | so we have presumably 1 module that needs upload of some firmware: WLAN+BT. And we have one module that has on-board firmware that can get updated: WWAN cell modem |
17:01.05 | edwin | for the FSF I think #1 would be a huge problem, #2 is probably something they can live it (perhaps if you cripple the update interface like on that laptop, although that wouldn't help much) |
17:01.32 | edwin | how about the GPU? I think thats mentioned on the webpage already |
17:01.58 | DocScrutinizer05 | we have a chip we will program permanently (SLG46721V) and we have a MCU we will also program permanently with a bootloader that allows user to upload own code for NFC |
17:02.14 | DocScrutinizer05 | we don't care about FSF |
17:02.59 | DocScrutinizer05 | GPU needs proprietary firmware for 3G part of opengl-es |
17:03.07 | DocScrutinizer05 | 2G is FOSS afaik |
17:03.14 | edwin | if you don't need 3D it'll still boot though right? |
17:03.20 | DocScrutinizer05 | yes |
17:03.53 | edwin | good point about FOSS for GPU, I think thats important to mention too |
17:04.01 | edwin | there's a difference between firmware blob, and userspace blob |
17:04.06 | edwin | and kernel blob |
17:04.51 | edwin | if I got it right you'll only need firmware blobs for Neo900 |
17:05.05 | DocScrutinizer05 | there's particularly a difference between code that executes on linux CPU and data of unknown nature (maybe some program?) that I need to upload into a chip and never again will see it |
17:05.08 | edwin | no userspace or kernel blobs are required (with the exception of 3D?) |
17:05.37 | DocScrutinizer05 | aaah, that's your definition. Yes |
17:06.00 | DocScrutinizer05 | no blobs in linux userspace or kernel |
17:06.19 | DocScrutinizer05 | only some data files to upload to a module, via a FOSS interface and driver |
17:06.44 | DocScrutinizer05 | (with exception of 3D) |
17:07.33 | edwin | having open source firmware would of course be nice, but you can't really do anything about it. Are you aware of alternative chips which have open source firmware ? |
17:07.46 | DocScrutinizer05 | no |
17:08.03 | DocScrutinizer05 | seems there are none. Atheros WLAN isn't meant for embedded |
17:08.22 | DocScrutinizer05 | their embedded series is notably not FOSS |
17:09.09 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?p=1483000#post1483000 |
17:10.34 | edwin | I think the only place where it might seem you have a choice is the GPU, different GPUs have various reverse engineered drivers in various states. But changing the GPU means you have to change the CPU and the whole SoC... |
17:15.56 | edwin | http://listas.gnu.org.ve/pipermail/powervr-devel/2015-July/000156.html |
17:16.04 | edwin | maybe the GPU is not so hopeless after all |
17:16.30 | DocScrutinizer05 | I know |
17:18.45 | edwin | DocScrutinizer05: 2G is FOSS afaik |
17:18.45 | edwin | ^you probably meant 2D |
17:18.56 | DocScrutinizer05 | yes |
17:19.14 | edwin | bbl |
17:34.48 | Wizzup | There is a 2d unit in the neo900? |
17:38.56 | DocScrutinizer05 | the PVR library is only 2D in FOSS version, afaik |
17:39.26 | DocScrutinizer05 | there's a 3D unit in Neo900 resp OMAP3: called PowerVR GX530(?) |
17:43.36 | Wizzup | checks elinux.org/N900 |
17:45.02 | DocScrutinizer05 | <PROTECTED> |
17:45.23 | DocScrutinizer05 | pvrsrvkm omaplfb |
17:45.55 | Wizzup | ah, if you use a specific ddx |
17:46.04 | DocScrutinizer05 | ddx? |
17:46.25 | Wizzup | device dependent x driver (like xf86-video-foo) |
17:46.39 | DocScrutinizer05 | o.O |
17:47.39 | DocScrutinizer05 | how's SGX530 existence and the driver library for OpenGL-ES related to X? |
17:48.00 | DocScrutinizer05 | related maybe, not depending on X anyway |
17:48.20 | Wizzup | well, I'm confused regardless. for some gpus you need to use a specific ddx to get accel |
17:48.23 | DocScrutinizer05 | some special X11 might depend on OpenGL |
17:48.23 | Wizzup | like with xf86-video-radeon |
17:48.39 | Wizzup | I mean, I expect the 2D to not be done using opengl/opengles? |
17:48.47 | Wizzup | Some units have dedicated 2d units |
17:48.52 | Wizzup | I guess the powervr does 2d as well |
17:49.06 | Wizzup | I mostly know too little about the situation - don't mind me :D |
17:50.08 | DocScrutinizer05 | yes, you need to use a enabled game to make use of the Okulus rift. That doesn't mean okulus rift depends on that game |
17:50.33 | Wizzup | huh? :) |
17:50.57 | DocScrutinizer05 | when you want to use 3D under X11, you might need a special X11 that supports acceleration from SGX530 hardware via OpenGL-ES library |
17:51.34 | DocScrutinizer05 | and then you need a special app that makes use of the 3D accel provided by the special X11 |
17:51.41 | Wizzup | A X11 driver, not a special Xorg X11, but yes |
17:53.30 | *** join/#neo900 Mentalysion (~quassel@ipservice-092-209-014-213.092.209.pools.vodafone-ip.de) |
17:54.12 | DocScrutinizer05 | I don't know if OpenGL-ES lib actually might have dependencies on X11 |
17:54.19 | *** join/#neo900 SylvieLorxu (~TheLastPr@dhcp-077-251-165-191.chello.nl) |
17:54.28 | DocScrutinizer05 | I doubt it though |
17:56.17 | Wizzup | Linux graphics situation is not trivial. You can do 3d without X, but it's not typical |
17:56.29 | Wizzup | I just wondered what part in the neo900 would do the accelerated *2D* |
17:56.35 | DocScrutinizer05 | yes, of course |
17:56.47 | Wizzup | but perhaps you were not talking about accelerated 2d |
17:56.53 | Wizzup | and just about mode setting/output |
17:57.01 | DocScrutinizer05 | I talked about PVR |
17:57.20 | DocScrutinizer05 | which has only 2D FOSS OpenGL-ES lib |
17:57.38 | Wizzup | that surprises me :-) cool |
17:57.59 | DocScrutinizer05 | since we don't ship OS, I can't say who does what with the PVR |
17:58.04 | Wizzup | Not sure what 2d opengl-es is, though |
17:59.29 | Wizzup | OpenGL and OpenGL-ES are both 3D acceleration APIs. While it is true you can use them for 2D acceleration (GLAMOR, or mplayer video scaling), it doesn't happen too often |
17:59.52 | Wizzup | Typically one does accelerated graphics in X, although for some time DirectFB was an interesting alternative |
17:59.52 | DocScrutinizer05 | *sigh* |
17:59.58 | Wizzup | What am I missing here? |
18:00.13 | Wizzup | I just just don't understand 2D FOSS OpenGL-ES lib |
18:00.15 | DocScrutinizer05 | the facts I mentioned above |
18:00.24 | Wizzup | What is a 2D OpenGL-ES lib? |
18:00.44 | DocScrutinizer05 | well, prolly a lib that has reduced functionality |
18:01.25 | Wizzup | Do you have a link? Nevermind if the conversation seems useless, I just think there's some misunderstanding here |
18:02.05 | DocScrutinizer05 | I got no link. And I don't think there's a missunderstanding. |
18:03.04 | DocScrutinizer05 | ImageTech/TI provides a BLOB that does OpenGL-ES 2.0 with 3D functions, and afaik there's a FOSS version that only can do 2D functions |
18:03.14 | Wizzup | Ok, I challenge the existance of a 2D OpenGL-ES lib, since OpenGL(-ES) is inherently 3D |
18:03.21 | Wizzup | but OK, sounds awesome. |
18:03.27 | Wizzup | Would be nice if that exists. |
18:03.38 | DocScrutinizer05 | headdesks |
18:03.57 | Wizzup | I think you'll find that what I am saying is less odd than you think it is :-/ |
18:04.02 | DocScrutinizer05 | what's unclear in a lib that can't do the 3D-related function calls |
18:05.28 | Wizzup | Any 2D done with OpenGL is inherently 3D, just a projection onto 2D. That is what is unclear. |
18:05.31 | DocScrutinizer05 | I never had a look into it since I'm not a developer of that stuff and never used it either, but to me it's pretty obvious what it means when a math lib can't do real but only integer math, or a lib can't do the 3D stuff but only the 2D bits |
18:06.53 | DocScrutinizer05 | for simplifying this, let's just assume that for arbitrary function calls in FOSS OpenGL-ES, Z<>0 is not allowed |
18:07.18 | Wizzup | That is possible, but I would find it very interesting if that was done |
18:07.19 | *** join/#neo900 Mentalysion (~quassel@ipservice-092-209-014-213.092.209.pools.vodafone-ip.de) |
18:07.23 | Wizzup | But yeah, not impossible. |
18:07.35 | Wizzup | but it would be quite odd |
18:07.37 | DocScrutinizer05 | sorry, I'm busy |
18:07.40 | Wizzup | okay, np |
18:08.33 | DocScrutinizer05 | what's odd in no Z-buffer supported, no shading, no perspective, no... dunno what shit - fog, younameit |
18:09.45 | DocScrutinizer05 | find the FOSS OpenGL implementation for PowerVR and you'll find the details in the readme there, I'd guess |
18:09.50 | ds2 | what about textures? |
18:45.56 | *** join/#neo900 tomeff_ (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) |
18:51.01 | *** join/#neo900 paulk-collins (~paulk@gagarine.paulk.fr) |
19:03.15 | edwin | how about render acceleration? |
19:03.58 | edwin | that can be done either by the Xorg DDX, or through OpenGL by using glamor to translate the 2D RENDER calls to OpenGL calls |
19:04.14 | edwin | there are also hardware overlays for video playback |
19:04.23 | edwin | and hardware decode of certain video formats |
19:09.02 | edwin | I suppose 2D accel refers to EXA, or SNA or something like that too: https://en.wikipedia.org/wiki/EXA |
19:09.08 | Wizzup | If the DDX does that |
19:15.27 | *** join/#neo900 Wizzup (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
19:24.24 | *** join/#neo900 vakkov (~vakkov@ic-s221n18.brunel.ac.uk) |
19:26.47 | *** join/#neo900 jonsger (~Thunderbi@2a02:8070:791:2f00:5448:2eb1:10:6c24) |
19:58.36 | *** join/#neo900 arossdotme-planb (~zxy@79-69-203-127.dynamic.dsl.as9105.com) |
21:10.38 | *** part/#neo900 brendafdez (~Brenda@unaffiliated/brendafdez) |
22:24.28 | *** join/#neo900 misv_ (~ms@128.199.49.125) |
22:29.00 | *** join/#neo900 dos1 (~dos1@unaffiliated/dos1) |
22:29.00 | *** mode/#neo900 [+v dos1] by ChanServ |
22:38.18 | *** join/#neo900 mzki (~koza@89-72-165-101.dynamic.chello.pl) |
23:49.13 | *** join/#neo900 Oksana (~chatzilla@Maemo/community/council/Wikiwide) |