00:01.51 | *** join/#htc-linux rzk_ (n=rzk@daemonet.ru) |
00:40.41 | *** join/#htc-linux Shinto (n=John@f049115073.adsl.alicedsl.de) |
00:50.02 | *** join/#htc-linux BHSPitLappy (n=BHSPitLa@unaffiliated/bhspitmonkey) |
01:13.36 | *** join/#htc-linux maejrep (n=madcoder@c-71-225-60-178.hsd1.pa.comcast.net) |
01:33.37 | *** join/#htc-linux pigeon (n=pigeon@eth5284.nsw.adsl.internode.on.net) |
01:53.38 | *** join/#htc-linux stickboy (n=anonymou@ool-457e4101.dyn.optonline.net) |
02:01.01 | *** join/#htc-linux Amaranth_ (n=travis@ubuntu/member/Amaranth) |
03:08.35 | *** join/#htc-linux mrmoku|away (n=mrmoku@ppp-93-104-117-159.dynamic.mnet-online.de) |
03:11.52 | *** join/#htc-linux BHSPitMonkey (n=stephen@unaffiliated/bhspitmonkey) |
04:13.38 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
04:45.07 | *** join/#htc-linux timebomb (n=tb@e177138160.adsl.alicedsl.de) |
04:55.37 | *** join/#htc-linux droid0011 (n=mc@p4FDCE9BA.dip.t-dialin.net) |
05:28.30 | *** join/#htc-linux ChanServ (ChanServ@services.) |
05:28.30 | *** join/#htc-linux elysion_ (i=kiiski3@mustatilhi.cs.tut.fi) [NETSPLIT VICTIM] |
05:28.30 | *** join/#htc-linux ccube_ (n=ccube@ssh.ccube.de) [NETSPLIT VICTIM] |
05:28.30 | *** mode/#htc-linux [+o ChanServ] by irc.freenode.net |
05:28.44 | *** join/#htc-linux jobo (n=jobo@5ED40048.cable.ziggo.nl) [NETSPLIT VICTIM] |
05:29.05 | *** join/#htc-linux Amaranth (n=travis@ubuntu/member/Amaranth) [NETSPLIT VICTIM] |
05:29.05 | *** join/#htc-linux pigeon (n=pigeon@eth5284.nsw.adsl.internode.on.net) |
05:29.05 | *** join/#htc-linux furtardo (n=mks@nat/yahoo/x-09b8ceef104e9875) [NETSPLIT VICTIM] |
05:29.05 | *** join/#htc-linux no2chem2 (n=no2chem@cpe-76-90-65-27.socal.res.rr.com) [NETSPLIT VICTIM] |
05:29.05 | *** join/#htc-linux Kevin2 (n=Kevin2@207-237-194-161.c3-0.avec-ubr2.nyr-avec.ny.cable.rcn.com) [NETSPLIT VICTIM] |
05:34.06 | *** join/#htc-linux MikeKnoop (n=mk@173-30-132-211.client.mchsi.com) |
05:34.32 | MikeKnoop | hello |
05:34.42 | MikeKnoop | anyone know if xda has a general IRC room? |
05:35.29 | tmzt | #xda-dev |
05:36.35 | MikeKnoop | on freenode? looks empty to me :) |
05:37.03 | tmzt | #xda-devs |
05:37.07 | tmzt | busy |
05:37.27 | MikeKnoop | ah, thanks man |
05:48.13 | *** join/#htc-linux Amaranth (n=travis@74-221-34-123.longlines.com) |
06:04.27 | *** join/#htc-linux Amaranth (n=travis@ubuntu/member/Amaranth) |
06:35.34 | *** join/#htc-linux kiozen (n=oeichler@p54921429.dip0.t-ipconnect.de) |
07:13.20 | *** part/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
08:01.54 | *** join/#htc-linux methril|work (n=Methril@127.Red-80-38-102.staticIP.rima-tde.net) |
08:08.35 | *** join/#htc-linux kynky (n=robert@kynky.net) |
08:46.55 | *** join/#htc-linux ptitjes (n=didier@AVelizy-154-1-30-98.w82-124.abo.wanadoo.fr) |
08:49.06 | *** join/#htc-linux g55 (n=g55@rgnb-5d87cc2e.pool.einsundeins.de) |
08:49.34 | *** join/#htc-linux silent-hacker (n=janus@unaffiliated/silent-hacker) |
08:50.11 | *** join/#htc-linux ArteK (n=Artur@81.15.241.96) |
08:52.17 | *** join/#htc-linux swc|666 (n=infidel2@unaffiliated/swc666/x-4934821) |
08:58.32 | silent-hacker | hello there |
08:59.57 | *** join/#htc-linux k_shaurya (n=administ@117.241.65.159) |
09:03.06 | k_shaurya | Hello, I wanted to know whether the Buttons and keys defined under input.h can be arbitrarily used in the board-...c file as in like BTN_0, BTN_1 |
09:18.51 | silent-hacker | hey guys, are there any members frm the HaRET team? i've got things to ask them |
09:20.21 | *** join/#htc-linux silent-hacker (n=janus@unaffiliated/silent-hacker) |
09:38.16 | k_shaurya | I'm not in the team, but whats the issue? |
09:42.09 | silent-hacker | k_shaurya: i'm trying to boot a linux distro on a epc 700 , arm z228 arm926ej processor |
09:42.34 | k_shaurya | hmmm...I'm working on an OMAP board |
09:42.41 | silent-hacker | ^^ |
09:43.31 | silent-hacker | do you have an idea on how i could find the ram start address for the boot? |
09:44.04 | k_shaurya | perhaps on the board-(your board).c file in asm/arch? |
09:44.21 | k_shaurya | sory |
09:44.23 | k_shaurya | arch/arm |
09:47.16 | silent-hacker | i'll dig that thx |
09:58.24 | *** join/#htc-linux BabelO (n=fcr@unaffiliated/babelo) |
10:00.34 | *** part/#htc-linux kynky (n=robert@kynky.net) |
10:01.19 | *** part/#htc-linux droid0011 (n=mc@p4FDCE9BA.dip.t-dialin.net) |
10:09.40 | *** join/#htc-linux droid001 (n=mc@p4FDCE9BA.dip.t-dialin.net) |
10:25.47 | *** join/#htc-linux ccube_ (n=ccube@ssh.ccube.de) |
10:25.47 | *** join/#htc-linux elysion_ (i=kiiski3@mustatilhi.cs.tut.fi) [NETSPLIT VICTIM] |
10:25.49 | *** join/#htc-linux jobo (n=jobo@5ED40048.cable.ziggo.nl) [NETSPLIT VICTIM] |
10:26.16 | *** join/#htc-linux kiozen (n=oeichler@p54921429.dip0.t-ipconnect.de) [NETSPLIT VICTIM] |
10:26.16 | *** join/#htc-linux Amaranth (n=travis@ubuntu/member/Amaranth) [NETSPLIT VICTIM] |
10:26.16 | *** join/#htc-linux pigeon (n=pigeon@eth5284.nsw.adsl.internode.on.net) |
10:26.16 | *** join/#htc-linux furtardo (n=mks@nat/yahoo/x-09b8ceef104e9875) [NETSPLIT VICTIM] |
10:26.16 | *** join/#htc-linux no2chem2 (n=no2chem@cpe-76-90-65-27.socal.res.rr.com) [NETSPLIT VICTIM] |
10:26.16 | *** join/#htc-linux Kevin2 (n=Kevin2@207-237-194-161.c3-0.avec-ubr2.nyr-avec.ny.cable.rcn.com) [NETSPLIT VICTIM] |
10:37.59 | *** join/#htc-linux ChanServ (ChanServ@services.) |
10:37.59 | *** mode/#htc-linux [+o ChanServ] by irc.freenode.net |
11:05.08 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
11:29.47 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
11:38.23 | *** join/#htc-linux marex (n=marex@thor.hackndev.com) |
11:45.48 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
11:59.27 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
12:19.32 | *** join/#htc-linux l1q1d (n=quassel@93.37.136.221) |
12:20.42 | l1q1d | hi to all! |
12:33.22 | *** join/#htc-linux k4r1m (n=hai@S0106001d7eddf34c.ed.shawcable.net) |
13:27.04 | *** join/#htc-linux MethoS- (n=clemens@host-091-097-244-143.ewe-ip-backbone.de) |
13:28.36 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
13:33.24 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
13:42.42 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
13:45.49 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |
13:45.59 | *** join/#htc-linux mugsie (n=Administ@unaffiliated/mugsie) |
13:46.06 | *** part/#htc-linux mugsie (n=Administ@unaffiliated/mugsie) |
13:49.05 | AstainHellbring | morning |
13:51.26 | *** join/#htc-linux ngupta (n=kvirc@59.164.186.211) |
13:53.37 | ngupta | Hi, I'm writing a driver for ARM which export statistics through ioctl interface. Strangely, all the data sent to userspace (using copy_to_user()) is corrupt. The same thing works fine on x86_64. Anyone has clues what can be wrong? |
13:56.48 | ngupta | ... or any mailing list where I can get help? |
13:57.11 | Weiss | kernelnewbies might be the right place.. but you'll need to show some code |
13:57.22 | Weiss | maybe you enacted some kind of dodginess with your pointers? |
13:59.45 | ngupta | I posted code at: http://fpaste.org/paste/19993 |
14:05.11 | Weiss | do you have an example of the ioctl being called from userspace? |
14:06.05 | ngupta | struct ramzswap_ioctl_stats stats; |
14:06.06 | ngupta | <PROTECTED> |
14:06.06 | ngupta | <PROTECTED> |
14:06.06 | ngupta | <PROTECTED> |
14:06.06 | ngupta | <PROTECTED> |
14:06.06 | ngupta | <PROTECTED> |
14:06.08 | ngupta | <PROTECTED> |
14:07.13 | *** join/#htc-linux jensen_ (n=jensen@3905ds1-ksa.0.fullrate.dk) |
14:07.31 | ngupta | ON_ERR() checks if ret == -1 in which case it bails out with a warning. |
14:08.51 | Weiss | i think it should check for ret < 0 |
14:10.07 | ngupta | ioctl manpage says: "On error, -1 is returned, and errno is set appropriately." |
14:10.57 | Weiss | ah, ok |
14:14.29 | Weiss | i should really be able to spot why that isn't working, but i haven't yet reached the required level of intuitive understanding i'm afrai |
14:14.33 | Weiss | +d |
14:36.59 | *** join/#htc-linux mugsie1 (n=Administ@unaffiliated/mugsie) |
14:37.05 | *** part/#htc-linux mugsie1 (n=Administ@unaffiliated/mugsie) |
14:39.52 | *** join/#htc-linux SOG (n=SOG@n220246172033.netvigator.com) |
14:50.24 | *** join/#htc-linux stefan_schmidt (n=stefan@w1431.wlan.rz.tu-bs.de) |
14:51.35 | *** join/#htc-linux sdt555 (n=titus@147.145.40.44) |
14:52.26 | *** part/#htc-linux sdt555 (n=titus@147.145.40.44) |
15:07.03 | *** join/#htc-linux Captnoord (n=Captnoor@dc5147a47b.adsl.wanadoo.nl) |
15:49.20 | *** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
15:51.35 | *** part/#htc-linux k_shaurya (n=administ@117.241.65.159) |
15:52.40 | *** join/#htc-linux stickboy (n=anonymou@ool-457e4101.dyn.optonline.net) |
15:53.10 | *** join/#htc-linux MikeKnoop (n=mk@173-30-132-211.client.mchsi.com) |
15:56.16 | *** join/#htc-linux g55 (n=g55@rgnb-5d87c888.pool.einsundeins.de) |
15:57.20 | *** join/#htc-linux pH5 (n=ph5@e178212133.adsl.alicedsl.de) |
16:02.58 | *** join/#htc-linux NetRipper (n=netrippe@netripper.nl) [NETSPLIT VICTIM] |
16:16.37 | *** join/#htc-linux dzo (n=dzo@mail.marginz.co.nz) [NETSPLIT VICTIM] |
16:23.55 | *** join/#htc-linux Echo31 (n=olivier@mir31-4-82-240-194-54.fbx.proxad.net) |
16:32.06 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) |
16:34.00 | *** join/#htc-linux kiozen (n=oeichler@rgnb-5d87d6c6.pool.einsundeins.de) |
16:53.29 | *** join/#htc-linux pH5_ (n=ph5@e178193018.adsl.alicedsl.de) |
17:29.31 | *** join/#htc-linux luc_ (n=luc@89-115-128-35.cl.ipv4ilink.net) |
17:39.50 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
17:41.14 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
17:42.35 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
17:51.39 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
18:21.33 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
18:53.35 | *** join/#htc-linux l1q1d (n=quassel@93.37.138.169) |
19:25.17 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
19:28.54 | *** join/#htc-linux onen|openBmap (n=quassel@mry91-1-89-87-198-158.dsl.club-internet.fr) |
19:37.25 | *** join/#htc-linux googleman (n=sdfddd@41.105.14.151) |
19:37.32 | googleman | hi all |
19:39.48 | AstainHellbring | hi |
19:53.13 | *** join/#htc-linux k_shaurya (n=administ@117.241.65.159) |
19:59.45 | *** part/#htc-linux k_shaurya (n=administ@117.241.65.159) |
20:04.56 | tmzt | Weiss: about the ioctls you use? |
20:13.13 | *** join/#htc-linux ChanServ (ChanServ@services.) |
20:13.13 | *** mode/#htc-linux [+o ChanServ] by irc.freenode.net |
20:13.19 | Weiss | tmzt: what about them? |
20:13.28 | googleman | any tried to run android on htc vox ? |
20:14.14 | tmzt | are you using your own? |
20:14.23 | googleman | ya |
20:14.34 | tmzt | and your own libdrm |
20:14.41 | googleman | ? |
20:14.59 | tmzt | try #linwizard or #winglinux |
20:15.05 | tmzt | try #linwizard or #wing-linux |
20:16.02 | googleman | tmzt what phone u have ? |
20:17.22 | Weiss | tmzt: some of them are driver-specific: DRM_IOCTL_GLAMO_GEM_CREATE (create a new buffer object), DRM_IOCTL_GLAMO_CMDBUF (submit commands to the hardware), and a few others. others, like DRM_IOCTL_GEM_OPEN, DRM_IOCTL_GEM_CLOSE etc, are platform-independent. our libdrm has a driver-specific header file and an independent one |
20:18.13 | Weiss | also, it's worth noting that the "driver-specific" parts of our libdrm were generated simply by doing "s/radeon/glamo/g" on the radeon driver-specific libdrm. it's very little beyond a thin wrapper around the ioctls |
20:19.37 | googleman | Weiss what r u tring to do ? |
20:19.45 | *** join/#htc-linux g55 (n=g55@rgnb-5d87cc4d.pool.einsundeins.de) |
20:19.45 | tmzt | ah |
20:19.49 | tmzt | ok |
20:20.08 | tmzt | since it has dedicated gpu memeory? |
20:20.25 | tmzt | so you are using gem? |
20:21.18 | Weiss | yep. GEM is really just the interface though. i wrapped GEM around a very simple block allocator. we hope to do some clever stuff wrt reference counting and eviction a bit later on |
20:21.43 | Weiss | googleman: DRI on a FreeRunner :) |
20:22.00 | tmzt | okay |
20:22.17 | tmzt | I'm going to be developing on intel though |
20:22.40 | tmzt | and we don't have dedicated gpu memory on msm7k |
20:23.53 | Weiss | what do you mean by "developing on intel"? |
20:23.58 | Weiss | basing your work on intel? |
20:24.27 | *** join/#htc-linux miknix (n=miknix@gentoo/developer/miknix) |
20:25.44 | Weiss | on the intel driver* |
20:25.59 | tmzt | I mean on my laptop |
20:26.18 | tmzt | well, I'm not going to start with dri it looks like |
20:26.27 | tmzt | fbdev and flipping |
20:26.29 | Weiss | ah, that makes no difference, just makes each compile/test cycle take a little longer |
20:27.03 | tmzt | since raster said compositing should be done on arm |
20:27.07 | Weiss | that's probably not a bad strategy. getting to grips with DRI is a very steep learning curve |
20:27.50 | tmzt | when phone works I will reconsider adding drm and dri to the server component |
20:27.55 | Weiss | yeah |
20:28.22 | tmzt | I thought I could use gem to manage pixmaps |
20:28.29 | Weiss | hmm.. on msm7k, you have the ARM core and graphics core all accessing the same pool of memory? |
20:28.36 | tmzt | maybe since they are in ram it's possible |
20:28.50 | tmzt | yes |
20:29.05 | tmzt | except google's driver uses physical addresses |
20:29.15 | tmzt | we would ioremap it |
20:29.28 | Weiss | do you have the specs of the CPU and GPU? if both are only capable of operating on one pixel per clock cycle, then raster will be right |
20:29.43 | tmzt | no |
20:29.52 | tmzt | we have two 'gpu''s |
20:30.10 | tmzt | one is the 2d engine called mdp |
20:30.28 | Weiss | in the Glamo case, things are different- we want to put the pixmaps in the VRAM, then do as much work as possible in the GPU with as little movement of information CPU<-->GPU (since that bus is extremely slow, as i'm sure you know) |
20:30.31 | tmzt | the other is fixed pipieline ati core with no specs |
20:30.45 | tmzt | yeah |
20:30.58 | tmzt | the stuff last night was interesting |
20:31.22 | tmzt | that it can't even split the ram |
20:31.37 | *** join/#htc-linux onen|openBmap (n=quassel@mry91-1-89-87-198-158.dsl.club-internet.fr) |
20:31.38 | tmzt | for cpu dma or sd operations |
20:32.02 | Weiss | yeah |
20:32.15 | tmzt | or even an enable bit to latch the registers |
20:32.34 | tmzt | so you can change mode |
20:33.09 | Weiss | hmm, i didn't see that part..? |
20:34.17 | tmzt | about wsod |
20:34.24 | tmzt | on rotate |
20:34.49 | no2chem2 | ahb2dati? |
20:35.04 | tmzt | ? |
20:35.18 | tmzt | msm7k |
20:35.47 | no2chem2 | ahi2dati* |
20:36.11 | tmzt | which is? |
20:36.44 | no2chem2 | some kind of data bus for moving stuff to the ati video |
20:36.47 | no2chem2 | mm bbl |
20:37.16 | tmzt | oh |
20:37.18 | no2chem2 | http://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture |
20:37.33 | tmzt | they are talking about glamo |
20:37.36 | no2chem2 | er, figure out how to access AHB on the 7k |
20:37.37 | no2chem2 | oh |
20:37.39 | tmzt | on freerunner |
20:37.56 | tmzt | we have google driver |
20:37.58 | no2chem2 | since you are on *nix, i would write some driver for ahb |
20:37.59 | no2chem2 | first |
20:38.08 | no2chem2 | then write a driver for dati |
20:38.11 | tmzt | and know where the memory is |
20:38.24 | no2chem2 | yeah |
20:38.26 | tmzt | well ok |
20:38.43 | tmzt | but I'm only dealing with mdp |
20:38.53 | tmzt | it won't be as fast as android |
20:39.17 | *** join/#htc-linux onen|openBmap (n=quassel@mry91-1-89-87-198-158.dsl.club-internet.fr) |
20:39.42 | no2chem2 | mdp is just framebuffer though? |
20:40.01 | tmzt | yes |
20:40.10 | tmzt | and some 2d ops |
20:40.49 | *** join/#htc-linux AntiXpucT (n=Skim@77.106.108.232) |
20:41.19 | Weiss | so, Android has some kind of binary blob driver for the ATI core? |
20:42.44 | tmzt | yes |
20:42.52 | tmzt | useing pmem driver |
20:43.11 | tmzt | which exports gpu memory to userspace |
20:44.48 | Weiss | but there is no dedicated GPU memory? (or there is for the ATI core?) |
20:45.01 | Weiss | sorry, i'm not familiar with this hardware |
20:46.53 | tmzt | no |
20:46.57 | tmzt | it's shared |
20:47.11 | tmzt | either internal or external ram |
20:47.25 | tmzt | internal means on soc |
20:47.28 | tmzt | not gpu |
20:52.28 | Weiss | i.e. ARM, MDP and ATI all use one pool of memory - no memory which "belongs" to either MDP or ATI involved anywhere? (i'm trying to be careful with my terminology, because of course memory in all three places might be directly addressable by the ARM core) |
20:53.15 | tmzt | I think it's all in arm11 address space |
20:53.41 | tmzt | mdp is what scans it out to lcd controller |
20:54.02 | tmzt | from gpu framebuffer, dsp or whatever |
20:54.16 | Weiss | i'd expect that though (in the FR case, Glamo's internal VRAM is in the ARM core's address space - you see what i'm trying to determine?) |
20:54.26 | tmzt | I think front and back are shared between gpu and mdp |
20:54.37 | tmzt | oh |
20:54.43 | *** join/#htc-linux onen|openBmap (n=quassel@mry91-1-89-87-198-158.dsl.club-internet.fr) |
20:54.46 | tmzt | what are you asking? |
20:55.55 | tmzt | yeah, I think it's just the two banks, internal to soc and external sdram |
20:55.57 | Weiss | i'm trying to work out whether you have something like an Intel integrated graphics system (where the GPU borrows all its memory from the main system memory, and "owns" no memory at all), or something more like Glamo, even though it's all on the same piece of silicon |
20:56.18 | tmzt | mdp and gpu use either internal or external ram |
20:56.25 | tmzt | nothing is dedicated |
20:56.38 | tmzt | similar to intel and agp/gart |
20:56.58 | Weiss | right, ok |
20:57.53 | tmzt | now, google's kernel dedicates the ram to the pmem driver, linux can't allocate it |
20:58.33 | tmzt | I hope that makes sense |
20:58.57 | tmzt | pmem is physical /dev/mem driver |
20:59.23 | Weiss | it dedicates *all* the memory to that, or just a bit of it? |
20:59.37 | tmzt | only what gpu needs |
20:59.55 | Weiss | ah, ok |
21:00.03 | Weiss | by "GPU", do you mean "ATI" here? |
21:00.07 | tmzt | yes |
21:00.37 | Weiss | and then there's some kind of binary blob involved? |
21:00.43 | tmzt | we only have kernel source to work from |
21:00.48 | tmzt | yeah |
21:01.04 | Weiss | ah, so all you have is a bit of information about how to poke its memory |
21:01.09 | tmzt | libhgl is loaded by a proces on android |
21:01.24 | tmzt | it maps the pmem regions into that process |
21:01.52 | tmzt | all of the binary stuff is userspace |
21:01.57 | tmzt | yeah |
21:02.06 | tmzt | but nothing like drm |
21:02.27 | tmzt | just the raw memory access gpl driver |
21:02.43 | Weiss | hmm.. i guess you have no indication of what the core actually is? (maybe it's not too different to, say, X300) |
21:02.58 | tmzt | imageon |
21:03.05 | tmzt | like old axims |
21:03.19 | tmzt | there's some source for them |
21:03.28 | tmzt | it's not radeon based |
21:03.42 | Weiss | ah, ok |
21:03.52 | tmzt | there's Xati or something |
21:04.00 | tmzt | a kdrive driver |
21:05.07 | tmzt | the project I'm working on is a display server with in process webkit plugins |
21:05.35 | tmzt | and later shm out of process npapi plugins |
21:06.10 | tmzt | based on raster's advice I'm going to have compositing in the display server |
21:06.14 | Weiss | why put that kind of thing in the display server? |
21:06.20 | Weiss | the web stuff, i mean |
21:07.05 | tmzt | well, it's an attempt to build something like Palm webos |
21:07.43 | tmzt | other options include X and wayland, which is why I am researching alternatives |
21:08.23 | *** join/#htc-linux infernix (i=nix@unaffiliated/infernix) |
21:08.23 | tmzt | X has not been optimized for composting managers on arm |
21:08.41 | tmzt | like compiz I mean |
21:09.08 | Weiss | i'm quite interested in Wayland for use on mobile devices |
21:09.20 | tmzt | not even sure kdrive can support a remote compisting manager |
21:09.35 | tmzt | yeah, I like the inprocess plugin approach |
21:09.45 | tmzt | but it doesn't work on fbdev |
21:10.26 | tmzt | I plan to get it running on my laptop with intel and work on a card manager for it |
21:10.31 | tmzt | like webos has |
21:10.42 | Weiss | yep, opening the door to this kind of thing is part of my motivation with KMS on Glamo |
21:10.43 | tmzt | even as a demo |
21:11.28 | tmzt | but the dri requirement in the clients makes it difficult |
21:11.34 | tmzt | if tfp doesn't work on msm |
21:11.34 | Weiss | yeah |
21:11.50 | Weiss | tfp? |
21:12.02 | tmzt | texture from pixmap |
21:12.31 | Weiss | ah |
21:14.05 | tmzt | is kristian interested in embedded stuff? |
21:14.30 | tmzt | I don't see much about it on the list |
21:15.03 | Weiss | don't know.. at least some of the core DRI developers are quite keen to work on SGX at some point, though, so maybe.. |
21:15.20 | tmzt | yeah |
21:15.34 | tmzt | I've seen some tesearch there |
21:15.39 | *** join/#htc-linux infernixx (i=nix@unaffiliated/infernix) |
21:15.52 | tmzt | maybe when op and gsm pre become available |
21:16.23 | tmzt | Palm isn't using egl at all from kernel source |
21:16.37 | tmzt | it's fbdev and pan |
21:16.37 | Weiss | op and gsm pre? |
21:16.46 | tmzt | openpandora |
21:16.52 | tmzt | palm pre |
21:17.13 | Weiss | ah |
21:28.00 | *** join/#htc-linux MethoS- (n=clemens@host-091-097-244-143.ewe-ip-backbone.de) |
21:50.49 | *** join/#htc-linux neutron (n=neutron@217-100-186.400720.adsl.tele2.no) |
21:58.12 | *** part/#htc-linux ArteK (n=Artur@81.15.241.96) |
22:02.12 | *** join/#htc-linux the-razer (n=daniel@91-66-39-196-dynip.superkabel.de) |
22:03.02 | tcccp | the-razer: o.O stalker ;) |
22:03.15 | the-razer | tcccp: ^^ |
22:03.56 | the-razer | tcccp: bekomm die woche mein htc touch pro... und ich freu mich shocn drauf, wenn android da dann endlich läuft! |
22:04.37 | tcccp | und ich muss nen neuen Linuxkernel fuer meinen HP iPaq baun |
22:05.01 | the-razer | ;-) |
22:08.31 | tcccp | Zuerst brauch ich mal ein zweites WRAP oder ein ALIX |
22:08.39 | tcccp | Ich glaube mein Router stirbt langsam und leise vor sich hin |
22:09.41 | the-razer | meiner hat auch grad stress gemacht. hatte da ne gemoddete version von tomato draufgeflasht, wegen VPN und nu durft ich ihn grad resetten weil garnix mehr ging -.- |
22:10.30 | tcccp | Bei mir funktioniert IPv4 komplett, aber ausser dem IPv6 tunnel...so garnichts mehr |
22:11.28 | the-razer | ich wollt mir für mein htc raphael n vpn anlegen und dann über meinen router zuhause gehen. so weià ich dann wneigstens, dass ich keine einschränkungen habe und kann auch gleichzeitig den traffic kleinhalten, weil der ja noch komprimieren kann |
22:46.56 | *** join/#htc-linux BHSPitMonkey (n=stephen@unaffiliated/bhspitmonkey) |
22:53.06 | *** join/#htc-linux darkstar62 (n=darkstar@97-126-107-190.tukw.qwest.net) |
23:08.23 | *** join/#htc-linux Amaranth (n=travis@74-221-38-55.longlines.com) |
23:23.52 | *** join/#htc-linux leaigor (n=laigor@188.134.36.14) |
23:48.44 | *** join/#htc-linux AstainHellbring (n=AstainHe@unaffiliated/astainhellbring) |