**** BEGIN LOGGING AT Sat Jul 18 02:59:56 2009 Jul 18 03:00:22 its kinda weird, the tutorial seems to imply the normal Xorg works fine even on the 680 so I would think centro would be no problem :/ Jul 18 03:00:52 it works, but much slower and more ram thab it should need Jul 18 03:02:42 yeah Jul 18 03:02:53 hmm, guess it's time to do some research heh Jul 18 03:04:05 so xserver-xfbdev won't cut it? Jul 18 03:08:05 yes Jul 18 03:08:29 did you find it? Jul 18 03:08:52 yeah, I think they have that package I believe the image is in or I can upgrade to Jul 18 03:08:58 let me get that rootfs loaded again Jul 18 03:12:20 /wi 11 Jul 18 03:27:42 so xfbdev is a modified kdrive? Jul 18 03:28:43 hmm, apparently just install Xfbdev Jul 18 03:29:28 raster: is that the same thing you're using in your rootfs? Jul 18 03:30:09 would appear to be so :) Jul 18 03:30:20 doing a dist-upgrade quick and will give it a try Jul 18 03:51:50 xfbdev -- kdrive Jul 18 03:51:57 == Jul 18 03:52:01 that's better :) Jul 18 03:52:02 ok Jul 18 03:52:14 kdrive builds single process/file xservers Jul 18 03:52:21 just run the server process for your hw Jul 18 03:52:25 yeah Jul 18 03:52:34 driver is compiled-in Jul 18 03:52:34 in this case one that uses fbdev video eh? Jul 18 03:52:40 yeds Jul 18 03:52:50 its named after the driver Jul 18 03:52:53 xfbdev Jul 18 03:52:54 hopefully it works :/ Jul 18 03:52:56 xglamo Jul 18 03:53:00 xati Jul 18 03:53:01 etc. Jul 18 03:53:06 yeah Jul 18 03:54:48 I wish _ was not so impossible to type on this centro keyboard heh Jul 18 03:57:34 ______! Jul 18 03:57:41 showoff :P Jul 18 03:57:54 using xchat on my laptop :) Jul 18 03:58:10 whenever I type a _ I always get &_, not to mention I have to press 3 keys to do it heh Jul 18 03:58:24 _-_-''-__-- Jul 18 03:59:24 brb Jul 18 04:14:11 raster: know anything about a generic ddx for dri/drm and modesetting? Jul 18 04:16:05 nup Jul 18 04:16:48 i like embedded Jul 18 04:17:04 invariably no modes, no settings Jul 18 04:17:11 u get the 1 fb at 1 res at 1 depth Jul 18 04:17:12 :) Jul 18 04:17:20 true Jul 18 04:17:23 (ok sometimes other fb's like overlays) Jul 18 04:17:31 and no "text mode" Jul 18 04:17:35 but things like pageflipping are done messy Jul 18 04:17:36 its really a q of what depth Jul 18 04:17:38 yes Jul 18 04:17:44 sure Jul 18 04:18:16 there's a patch on dri-devel for async pageflip Jul 18 04:18:21 waits for vsync Jul 18 04:18:30 that'll depend on the hw Jul 18 04:18:47 if async from an api pov it may be polling lower down anyway Jul 18 04:18:57 or not Jul 18 04:18:59 who knows Jul 18 04:19:19 the problem with flipping is that u need to redraw each a every frame Jul 18 04:19:23 the whole screen Jul 18 04:19:30 and thats pretty prohibitive Jul 18 04:19:40 yeah, if there's a bit on the pipe to indicate vsync or something Jul 18 04:19:45 what do you mean? Jul 18 04:19:52 yeah - some hw has vsync intrrupts, some doesnt Jul 18 04:19:53 why redraw each frame? Jul 18 04:19:56 some u have to poll-wait Jul 18 04:20:09 if u page filp - yopu have a brand new fb to display Jul 18 04:20:21 a page flip by definition flip the entire screen Jul 18 04:20:24 ah, right Jul 18 04:20:43 you can take sahoretcuts by copying the current displayed frontbuffer to the backbuffer, then modify it Jul 18 04:20:55 but one way or another every pixel on the screen must be touched Jul 18 04:21:06 by cpu? Jul 18 04:21:07 what i would like is a return to what the amiga did - a copper Jul 18 04:21:16 a processor that is hooked to the video scanout clock Jul 18 04:22:03 it can execute a simple instruction like read value ad address X and write to fixed address Y Jul 18 04:22:07 or write immediate to Y Jul 18 04:22:29 maybe a simpl loadimm, load, store Jul 18 04:22:45 I'm trying to see if it's worth converting the msm mdp driver to drm from fbdev with pan ioctl, whether we gain enough in userspace by eliminating a shm compositor (X server, etc) Jul 18 04:22:45 basically that could be used to flip only specific lines of the fb Jul 18 04:22:57 ah Jul 18 04:23:00 eg - create a coper list that at te start of each line sets the line address Jul 18 04:23:06 so you only flip the lines you changed Jul 18 04:23:10 and thus only redraw that Jul 18 04:23:27 useless for 3d - but for 2d, it would kick bum Jul 18 04:23:40 okay Jul 18 04:23:50 even better - if its hooked to clokc u'd be able to execute every Jul 18 04:23:57 pixel (or N pixels) Jul 18 04:24:02 you could thus implement tiles Jul 18 04:24:03 the mddi supports partial redraw Jul 18 04:24:53 it can push region updates to the lcd controller chip Jul 18 04:25:07 hmm that'll still be a copy Jul 18 04:25:17 there's be a shadow fb somewhere copied to Jul 18 04:25:22 it ends up the same Jul 18 04:25:29 yes Jul 18 04:26:09 even if hw did this - software api's dont handle it Jul 18 04:27:13 that's the question for me, is it worth to be able draw directly into the gpu memory from my client apps, particularly when they are either fullscreen or composited most of the time Jul 18 04:27:20 not in individual windows Jul 18 04:27:46 I think we will need this to make 3d work anyway Jul 18 04:28:21 for fullscreen 3d apps - they draw into the backbuffer and flip anyway Jul 18 04:28:41 i think it's more a matter of a single shared 3d backbuffer with clipping at the backbuffer level Jul 18 04:28:56 hmm though that is problematic in its own way with compositing Jul 18 04:29:31 in the end i think a compositing step is a price to pay and may as well keep payng it Jul 18 04:29:35 you want it to Jul 18 04:29:42 okay, 2d apps, I mean using the 3d gpu to speed up 2d but using an open driver Jul 18 04:29:44 1. force all app updates to be vsynced Jul 18 04:30:06 2. allow for saving of window content to do quick-bringup on start next time Jul 18 04:30:12 or for browsing apps runnings Jul 18 04:30:43 and yes - i'd use the 3d gpu to do 2d rendering Jul 18 04:31:19 it can do quite a bit. the problem is - for me so far my numbers have put using the cpu to draw 2d about 4x the speed of hw Jul 18 04:31:33 example - s3c6410 and omap3530 Jul 18 04:31:52 yes, that's the question, should we use pixmaps in a sever and a single frontbuffer/server pixmap Jul 18 04:31:55 well Jul 18 04:32:13 we only have the closed driver from g1 Jul 18 04:32:23 well to me - that makes total sense Jul 18 04:32:31 a texture and pixmap in modern gl are "the same" Jul 18 04:32:43 they are surfaces to use as source or as destinations for draws Jul 18 04:33:09 which is mapping the whole set of gpu registers from userspace Jul 18 04:33:11 lines, rect fills etc. are literally doable with simple filled tris Jul 18 04:33:46 right, but we don't have docs on gpu, so we have to mmiotrace that Jul 18 04:34:01 to even draw on tri Jul 18 04:34:04 one Jul 18 04:35:05 well technically you have libGL (ES) right? Jul 18 04:35:10 and EGL Jul 18 04:35:14 if we are going to do it, we would be using dri and putting some of the driver in kernel Jul 18 04:35:21 there is no good reason x cannot be built on top of that Jul 18 04:35:28 we do, from the closed driver Jul 18 04:35:49 then no need to mmio trace or put it in-kernel Jul 18 04:36:49 it has to be made to work on other msm devices, it seems it's possible though Jul 18 04:37:00 you couldnt use the same libGL for "client gl apps" Jul 18 04:37:02 ie dri Jul 18 04:37:09 you'd need a wrapper lib rto replace it Jul 18 04:37:25 yeah Jul 18 04:37:33 but if u have 1 working gles u can use to draw fullscreen - and it can do gles2... you are home and hosed Jul 18 04:37:36 it can only have one instance Jul 18 04:37:45 i cant remember is gles1.1 supports rendertotexture Jul 18 04:37:49 1.1 Jul 18 04:38:05 1 instance is ok Jul 18 04:38:10 you can fake other instances on top Jul 18 04:38:20 with the wrapper lib Jul 18 04:38:46 (of course i'm ignoring performance implications.... :)) Jul 18 04:39:02 how would we determine what the 2d processor could do? Jul 18 04:39:20 it seems only the most basic functions are being used Jul 18 04:39:32 by google and other drivers Jul 18 04:39:43 you mean generically without hw tech docs? Jul 18 04:39:54 yes Jul 18 04:39:58 no way to know Jul 18 04:40:08 it will vary per soc and per generation Jul 18 04:40:13 registers may exist - may not Jul 18 04:40:29 you may even have a complex commandqueue (pxa310+) Jul 18 04:40:33 but what's the minimum we need to accel bits, fills Jul 18 04:40:51 well they are just thaa blitter Jul 18 04:40:55 a blit/fill unit Jul 18 04:41:10 and you may have caveats Jul 18 04:41:13 eg "video memory" Jul 18 04:41:19 ie can only read/write to/.from it Jul 18 04:41:50 it may give you any src/dst format (pxa310) or may be limited (dst only rgb565 - not rgb32, but src cn bd rgb565, 555, rgba32 etc.) Jul 18 04:41:57 it may do 90 degree rotations or not Jul 18 04:42:09 you need a tech doc per cpu Jul 18 04:42:17 and how you talk to the hw will vary Jul 18 04:42:25 as i said - i've seen register and cmdqueue based Jul 18 04:42:39 i've seen smt (share same system ra but 2d can only access a window of it Jul 18 04:42:44 i've seen dedicated video ram Jul 18 04:43:23 i've seen oterh limits - like max "pixmap" (src/dest surface) size of 640x640 Jul 18 04:43:35 or 2048bytes (so divide by depth) Jul 18 04:44:17 things that only support 16bit or some that are amazingly-full-featured (pxa310 can have src or dst as anything from 555, 565, 24, 32 or even up to 64bit per pixel) Jul 18 04:44:27 and it will color-convert as needed for you for all ops Jul 18 04:45:46 glamo (smediatech 3662) will only do rgb555,565 or argb32 as a src - max pixmap size 640x640. doesnt support strides > 640x640 (so you need to tile all pixmaps and buffers to get accel. joy be handling this combined with transformations - eg scale) Jul 18 04:45:58 dest can only be rgb555 or 565 Jul 18 04:46:21 anyway - you dont know what it can do - there is no generic api to live up to or specirfied featureset minimum Jul 18 04:48:51 http://android.git.kernel.org/?p=kernel/msm.git;a=blob;f=drivers/video/msm/mdp.c;h=475e02efb32f4d07bd35b14c0a391a5ca8fa306e;hb=android-msm-2.6.29 Jul 18 04:49:09 haven't seen get/put-image before Jul 18 04:49:20 unlikely in kernel Jul 18 04:49:25 \its normally done in userspace Jul 18 04:49:28 ie in x Jul 18 04:49:31 need to run Jul 18 04:49:36 I thought everything was mmapped through fbdev Jul 18 04:49:40 hey, yhanks Jul 18 10:18:20 bluelightning: hey, I started working on palm stuff a little again, check my blog ;-) Jul 18 10:18:51 marex: awesome Jul 18 10:19:15 LifeDrive, someone was talking about wanting to run Linux on theirs recently on some mailing list, I forget which one Jul 18 10:19:49 well I made some maintainance even there ;-) Jul 18 10:20:23 now, if we could get usable kernels building properly in OE that would be truly brilliant ;) Jul 18 10:25:25 bluelightning: well, OE is up to you ;-) Jul 18 10:26:02 marex: argh :( Jul 18 10:50:04 bluelightning: looks like pxamci is broken again ... now that's something to say 'argh' about Jul 18 11:23:46 marex: so how should OE grab the latest TX-compatible kernel source at the moment? Jul 18 12:40:10 bluelightning: well can OE use git ? Jul 18 12:40:40 marex: yes Jul 18 12:40:41 if so, grab the ycmiao tree from (topic://RTFM.txt) Jul 18 12:40:54 marex: ok thx Jul 18 12:40:57 switch to devel branch ... that's the latest TX tree Jul 18 12:41:19 (there's a howto on doing it in the RTFM.txt file, but not for OE) Jul 18 12:42:14 bluelightning: btw did you get those few messages from Belldandy about the cpomilation issue ? Jul 18 12:42:20 *compilation Jul 18 12:43:02 marex: nope, never recieved them AFAIK Jul 18 12:46:28 bluelightning: you might get them in a while Jul 18 12:47:40 anyway, I think I just removed all mentionings of that macro and thta fixed the problem Jul 18 12:48:23 marex: you mean the #define? Jul 18 12:48:42 ah, got the messages now Jul 18 12:48:56 good ;-) Jul 18 12:49:12 I dont really recall, it should be in the messages Jul 18 12:49:32 btw other opie-image CVS version issues should now be fixed (at least with gcc 4.3.x) Jul 18 12:49:50 there were a few, sorry about that... Jul 18 13:34:18 bluelightning: np, I cant pull now (GPRS) and wont be able in near future (~a week) Jul 18 15:14:46 damn, Xfbdev server is still causing screen corruption, wtf Jul 18 21:47:06 Sleep_Walker: hey there :) Jul 18 21:47:33 * Sleep_Walker is already sleeping, try tomorow ;b Jul 18 21:47:37 hehe Jul 18 21:47:38 ok Jul 18 21:47:42 :) Jul 18 22:05:43 sigh, seems like the output from the modem in my centro is binary :/ Jul 18 22:22:15 did see a phone number fly by when someone tried to call me though :) Jul 19 02:26:50 raster: I think my screen corruption may have somthing to do with mode switching. I get the same exact type of corruption if my screen goes into standby while sitting at the console Jul 19 02:27:19 stupid debian, not building the scp client in their dropbear package... Jul 19 02:29:04 hehehe Jul 19 02:29:57 going to try your Xserver script along with your xserver-nodm script as they differ quite a bit from what's on the debian stuff Jul 19 02:30:08 just to see if passing explicit options to the Xserver somehow makes it work heh Jul 19 02:30:32 it has to be something in the rootfs though as this kernel+modules work fine on illume image :) Jul 19 02:31:43 wel thats just standard openembedded setup Jul 19 02:31:45 no-frills Jul 19 02:31:50 yeah I figured Jul 19 02:32:16 their approach seems quite a bit more direct then debian's approach of letting X figure it out heh Jul 19 02:33:32 the Xserver script has a bunch of specific command lines for each type of phon Jul 19 02:33:33 phone* Jul 19 02:33:42 wll for long enough each and eery device target has ben different and "fiddly" Jul 19 02:34:02 but luckily when you had a target - it had just 1 kind of scren Jul 19 02:34:02 I can imagine :) Jul 19 02:34:08 \it's built-in so you know what you have Jul 19 02:34:09 :) Jul 19 02:34:12 aye Jul 19 02:34:17 that'll be the day :P Jul 19 02:34:30 external monitors for your cell phone/pda :P Jul 19 02:34:56 gah, I hate when cocoboot reboots my phone... Jul 19 02:35:10 takes like a minute to boot this thing :/ Jul 19 02:35:49 yeah Jul 19 02:35:54 therews bonuses of not havng them Jul 19 02:35:56 u can chag res Jul 19 02:36:01 and thats good Jul 19 02:36:10 so teling x exactly whan u have - is good Jul 19 02:36:12 yah Jul 19 02:36:15 it actualy can['t probe Jul 19 02:36:18 which may why I'm having issues atm Jul 19 02:36:29 there is no"vesa" to go ask your screen what rews's ithas or what a native panelk size it is etc Jul 19 02:36:35 but it sounded like people had no problems with 680 with stock xorg Jul 19 02:36:41 tats demed pointlss on embedded Jul 19 02:36:42 and it is Jul 19 02:36:44 :) Jul 19 02:36:46 so maybe it's just a misplaced bit on the centro Jul 19 02:37:17 using ssh is so much better then trying to type on the phone itself :P Jul 19 02:37:37 indeed Jul 19 02:37:57 in fact if ucant get usbnet up - i generally just ignore the device Jul 19 02:37:59 this g_ether module is awesome, will have to remember it the next time I'm in a bind with not enough lan cables :) Jul 19 02:38:02 its 'useless' Jul 19 02:38:17 (well srial console is good - but it kind of sucks for scping things back and forth) Jul 19 02:38:26 or want to share my connection with others via wifi :) Jul 19 02:39:22 the only problem is the lack of standard for setup of the tcp layer Jul 19 02:39:43 ie what you want is a mini dhcpd that just listens on new usbX devices Jul 19 02:40:01 and the devices request dhcp configuration over it Jul 19 02:40:07 well I just have static ips and do forwarding, simple and it works :) Jul 19 02:40:25 preferably dhcpd for these would also set up masquerading and forwarding also by default Jul 19 02:40:29 sure Jul 19 02:40:34 you could have the phone use dhcp as long as your pc had a dhcp server no? Jul 19 02:40:39 that works... until youhave 6 of these babies pluged in Jul 19 02:40:45 heh Jul 19 02:41:10 well you'd need is spcially configured to ignore noral newrk devices on yourlaptop Jul 19 02:41:19 sigh...sometimes using ssh with this thing takes way too long Jul 19 02:41:21 and also setup up the masq Jul 19 02:42:07 I think I need to take hal off this damn phone too heh Jul 19 02:42:20 on this rootfs they left it there for X's auto config :P Jul 19 02:42:33 oe has ha too btw Jul 19 02:42:35 talk about a pig of a program :P Jul 19 02:42:36 hal Jul 19 02:42:44 by default and for X config? Jul 19 02:42:52 yes by default Jul 19 02:42:55 but noty for x config Jul 19 02:42:59 well the oe i have does Jul 19 02:43:31 its used for devices with wifi and removable storage Jul 19 02:43:37 ah Jul 19 02:43:38 it is there and use Jul 19 02:43:50 i guess that makes sense Jul 19 02:44:12 getting rid of hal frees up a ton of memory here :P Jul 19 02:45:45 base mem on oe with x and e+illume is about 12m Jul 19 02:46:12 ok Jul 19 02:46:14 brb Jul 19 02:51:35 raster: yay! Jul 19 02:51:51 an d back i iz Jul 19 02:51:55 I got X started, but seems to just bring up a fullscreen virt term in which I can't type anything in heh Jul 19 02:52:02 and I can see a text pointer Jul 19 02:52:07 which I can't move hh Jul 19 02:52:09 eh? Jul 19 02:52:14 that doenst smell of x Jul 19 02:52:16 but I can start/stop via xserver-nodm script fine Jul 19 02:52:19 hmm Jul 19 02:52:42 x itself without -br woiudl be a hatch-pattern Jul 19 02:52:49 otherwise it'd be e + illume as the session Jul 19 02:53:03 well if I match any of the conditions sure :) Jul 19 02:53:15 unless... you're somehow falling back to the fallback session of x + xserm Jul 19 02:53:17 but I may not match any since I have centro and not 650/680 Jul 19 02:53:17 lt m try somthing Jul 19 02:53:30 because you have a bastard-son of debin plus some oe bits Jul 19 02:53:31 i dont know Jul 19 02:53:52 hehe Jul 19 02:54:07 well I checked that awk it does to figure out what phone it is and it returned Palm Treo 680 Jul 19 02:54:17 so just need to tweak the script to recognize that string Jul 19 02:54:37 thats what i do when i add/fix a new platform Jul 19 02:54:43 i've done it a few times already in oe Jul 19 02:55:17 yeah, looking at it now, I see where it does the 650 case Jul 19 02:57:40 bah, now it's crashing out Xfbdev, hmm Jul 19 02:57:47 hahaha Jul 19 02:58:42 ok, might be the PPM screwing it up, odd Jul 19 02:59:08 nope, it's the -hide-cursor Jul 19 02:59:20 doesn't seem to recognize that one, is that an oe addition? Jul 19 02:59:33 thats an oe patch Jul 19 02:59:38 in fact so is ppm **** ENDING LOGGING AT Sun Jul 19 02:59:57 2009