[04:27] <warewolf> Sarvatt congrats on your job :)
[05:33] <bryceh> Sarvatt, welcome aboard :-)
[17:01] <penguin42> Does anyone know where the ioctls for radeon dri are defined for user space?
[17:03] <penguin42> oh maybe in an X server file rather than normal /usr/include/linux ?
[17:07]  * penguin42 finds libdrm
[17:42] <jg> ping Sarvatt 
[17:50] <penguin42> anyone understand drm_buffer_pointer_to_dword and friends?
[18:05] <X3> hi guys
[18:07] <X3> need help form someone experienced who can backport nvidia drivers and vdpau etc from 185 to 256 on karmic and lucid need to have a ppa which offers all those choices on one ppa
[18:07] <X3> its for this project https://sourceforge.net/projects/xci/
[18:17] <tjaalton> X3: https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates for lucid
[18:17] <tjaalton> maybe the same works for karmic
[18:18] <X3> er thats only offering 256 in lucid
[18:18] <X3> i need to offer choice from 185 up to 256
[18:18] <tjaalton> heh, good luck then
[18:19] <X3> oh thx for your help... not
[18:19] <tjaalton> 256 supports the same devices, so I don't understand what you're aiming for
[18:19] <X3> if you read about XCI you would know
[18:20] <X3> its a post installer script for xbmc some devices etc
[18:20] <X3> users not all want just one driver version
[18:20] <tjaalton> still doesn't answer the question
[18:21] <X3> diferent machines, setups, needs etc
[18:21] <tjaalton> yes, and if 185 works then 256 will
[18:21] <X3> really
[18:21] <tjaalton> well, it's nvidia...
[18:21] <tjaalton> so maybe not
[18:21] <X3> i must have droped IQ
[18:21] <tjaalton> but in theory it would
[18:22] <X3> in theory
[18:22] <X3> you would nderstand I need to offer a chice for my script users
[18:22] <X3> *choice
[18:23] <tjaalton> so to answer your question; no there is no place with every nvidia driver available since 185
[18:23] <X3> I know
[18:23] <X3> this is what Im trying to create
[18:23] <X3> nvidia ppa offers this for karmic
[18:24] <X3> but not for lucid
[18:24] <X3> and x swat only offers one dribver version
[18:24] <tjaalton> then ask whoever is providing that
[18:24] <X3> oh lord
[18:24] <tjaalton> oh sunday
[18:24] <X3> man why you making a easy requet into a nightmare
[18:25] <tjaalton> are you asking for someone to create a ppa for you?
[18:25] <X3> most importantly why am I listening to someone ewho clearly not helpfull
[18:25] <X3> ya I need someone whos experienced with drivers
[18:26] <tjaalton> trying to save you some time. it's rather pointless to provide that sort of choice to the users..
[18:26] <X3> oh right
[18:26] <tjaalton> hey, I maintained nvidia/fglrx for 8.04
[18:26] <X3> why they ask for it
[18:26] <X3> i have 6k users and they wanted choices
[18:27] <tjaalton> it's trivial to rebuild the package for a given distro
[18:27] <X3> trivial for u perhaps
[18:28] <tjaalton> dunno about forward-porting to a newer kernel, but shouldn't be too hard
[18:28] <X3> ah
[18:28] <tjaalton> dch, bump the version & change the release, debuild -S, dput
[18:28] <X3> your assuming that im experienced packager, in that case I wouldnt be asking for help
[18:29] <X3> its not that simple
[18:29] <X3> in order to have one ppa with several difernt versions of same the packages need renaming
[18:30] <X3> e.g. nvidia-drivers to nvidia-drivers-185
[18:31] <X3> otherwise the newer drivers just erase oldr ones on ppa
[18:31] <X3> also many of the packages have problems that require some attention
[18:31] <tjaalton> no it doesn't
[18:31] <tjaalton> oh
[18:31] <tjaalton> it does
[18:31] <X3> :/
[18:31] <tjaalton> well, see, it's pointless :)
[18:32] <X3> whats pointless is this discussion
[18:32] <tjaalton> indeed
[18:32] <penguin42> X3: Why don't you try cribbing from some other packages that do similar things?
[18:32] <X3> ?
[18:32] <penguin42> X3: Find another package which has 2 or 3 versions available and borrow the way they do it
[18:33] <X3> its any compile issues that need fixing as well as other things
[18:33] <X3> its not as simple as that
[18:34] <penguin42> X3: Yeh well I'm not sure where you're going to find someone to fix compile issues on so many versions - I guess it's hard enough just keep one or two versions built and working
[18:34] <X3> for choice and availability for all?
[18:34] <X3> nm
[18:34] <penguin42> X3: But it's a lot of work I guess; so I guess the people who know try and pick one or two versions which work for most
[18:35] <X3> LOL
[18:36] <X3> never mind Ill just do it myself
[18:36] <penguin42> well if you disagree find someone who wants to do it, but please don't laugh at us
[18:36] <X3> im not laughing at you
[18:36] <X3> ust at the defeatist attitudes
[18:36] <penguin42> X3: It really shouldn't need every version; it should just work with one or two
[18:37] <penguin42> X3: It's defeatist to build every damn version for every kernel
[18:37] <X3> im trying to help people with their projects andn i get the destinct message that says its hard work forget about it
[18:37] <tjaalton> X3: that's what happens after you've dealt with the blobs for some time
[18:37] <penguin42> X3: I'm not saying some hard work is a bad thing; but I'm saying its probably not the most useful thing
[18:38] <X3> Clearly you guys know nothing about XCI or xbmc users so nm
[18:38] <tjaalton> heh, do they differ from ubuntu users?-)
[18:38]  * penguin42 checks the channel title
[18:38] <X3> nm you guys have a dandy sunday I just found a useless channel
[18:39] <X3> ill do it all myself
[18:39] <penguin42> enjoy
[18:45] <tjaalton> penguin42: btw, did you try #dri-devel, or #radeon?
[18:52] <penguin42> tjaalton: Not yet, I've not get much time left today so I'll probably pick it up again next weekend
[18:53] <tjaalton> penguin42: okay
[18:53] <penguin42> tjaalton: But thanks for the reply
[18:54] <tjaalton> np
[18:54] <tjaalton> my better contribution for the day ;)
[18:54]  * penguin42 is working through the kernel with sparse and trying to understand some of the warnings; I've found some nice obvious bugs that I've reported - nice simple ones; but there are a few I want to think more about
[19:08] <Sarvatt> penguin42: /usr/include/libdrm/radeon_drm.h and drm_buffer_pointer_to_dword was added here - http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg46896.html
[19:08] <Sarvatt> jg: what's up?
[19:08] <Sarvatt> and ...wow... at the scrollback :D
[19:08] <penguin42> Sarvatt: Thanks
[19:09] <tjaalton> yeah, sorry about that
[19:10] <Sarvatt> why are YOU sorry? :D 
[19:10] <tjaalton> for feeding the troll?-)
[19:11] <jg> Sarvatt: I finally had a chance to get back to installing on my HP 2540p; Maverick installs, but the screen flashes at 1-2hz randomly.  So there is still some problem....
[19:13] <Sarvatt> whoa, really? with the massive amount of eDP fixes queued up for the kernel I'm surprised it's working
[19:13] <penguin42> jg: Weird bug!
[19:13] <jg> penguin42: almost certainly not quite driving the panel correctly...
[19:14] <jg> Sarvatt: so is there some version of bits I should try out, better than Alpha 3?
[19:14] <penguin42> jg: I've seen something similar on a Radeon with an old Dell 20" but it only happens sometimes
[19:15] <jg> penguin42: yeah, it's more than a bit distracting; I did find a previous kernel that behaves better.
[19:15] <penguin42> and it was much less specific, it tended to blink off just when you looked at it 
[19:15] <penguin42> but maybe that was the --spiteful option
[19:16] <Sarvatt> jg: not yet, the mainline kernels stopped building because one of the staging drivers is broken, hopefully intel gets the fixes into 2.6.36-rc2 that should be coming out soon and that'll be in here - http://kernel.ubuntu.com/~kernel-ppa/mainline/
[19:17] <Sarvatt> have you tried http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc1-maverick/ by any chance?
[19:18] <jg> Sarvatt: yes; was unstable and oopsed with dismaying frequency; I think it also flashed the screen at me, IIRC.
[19:20] <Sarvatt> how do you like that 2540p by the way? laptop shopping for something broken on linux :)
[19:21] <jg> Sarvatt: I like the machine a lot, except for the problem's I've been having under Linux.  It has a full sized keyboard; it's clearly very ruggedly built, and has a DP connector on it, which means I can drive just about any external display (at least when the bugs get shaken out...)
[19:22] <jg> It's relatively small, but bigger than this VAIO I hate intensely.
[19:23] <bjsnider> what's the chipset?
[19:23] <jg> Sarvatt: I haven't poked at all of the devices yet; dunno about the finger print reader, nor the support for SD, etc.
[19:24] <jg> bjsnider: http://h10010.www1.hp.com/wwpc/us/en/sm/WF06a/321957-321957-64295-3740645-3955549-4138624.html
[19:24] <Sarvatt> its just a normal qs57, i'm looking at the 14" version since its hard to justify paying that much for a 1280x800 screen
[19:24] <bjsnider> that should work perfectly fine with linux -- it's all intel
[19:25] <Sarvatt> eDP is all kinds of messed up on intel
[19:25] <Sarvatt> and the screen is connected over that internally so theres a bunch of problems
[19:25] <jg> Sarvatt: Intel® Core™ i7-640LM Processor (2.13 GHz, 4 MB L3 cache)
[19:28] <jg> Sarvatt: there is also a tablet version available (multitouch screen).
[19:28] <Sarvatt> it's a shame sony vaio z is the only decent 13" laptop with a non 1280x800/1366x768 screen :( i may just get a precision M6500 from the dell outlet for half price and stick to this netbook for traveling since it gets about 18 hours total battery life
[19:30] <jg> Sarvatt: I've liked my VAIO for traveling, but it has sucked for everything else; the HP is slightly bigger and heavier, but I get a full sized keyboard, and it's clearly much better made.
[19:32] <jg> will still be fine for traveling, and I can finally drive my big flat panel properly; the VAIO i have was very marginal on the video at that size.
[19:32] <Sarvatt> the $249 batteries on the vaio are putting me off on that with how much I go through them
[19:34] <Sarvatt> jg: when you say flashes, do you mean like it blanks and comes back? or things shift for a split second?
[19:35] <jg> no, the screen blanks out pretty completely.
[19:35] <Sarvatt> you could try booting with i915.powersave=0 added to the kernel command line, possibly i915.lvds_downclock=0 as well
[19:35] <jg> so flashes isn't really the right term; it's as if it turns off and on.
[19:38]  * penguin42 what's eDP?
[19:39] <Sarvatt> jg: how often does it happen? does it have any correlation to activity on the desktop at all?
[19:39] <Sarvatt> penguin42: embedded displayport
[19:40] <jg> Sarvatt: all the time; no correlation with what I'm doing otherwise.
[19:40] <penguin42> Sarvatt: Ah right
[19:40] <Sarvatt> its a standardized plug for lcd's internally on laptops
[19:41] <Sarvatt> jg: like every 10 seconds, every minute...? or just completely random?
[19:41] <jg> the command line options had no effect, on 2.6.36-17-generic.
[19:41] <jg> Sarvatt: like all the time, once or twice per second.
[19:41] <jg> Really bad....
[19:42] <Sarvatt> oh nasty :(
[19:42] <Sarvatt> probably not powersave related then but still worth a shot
[19:43] <jg> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc6-maverick/ is what I'm running, on which the video does not screw up.
[19:44] <jg> all in the launchpad bug reports....
[19:44] <Sarvatt> hmm, thats older than the maverick kernel, the maverick kernel doesn't work?
[19:44] <Sarvatt> i'll check the report
[19:45] <jg> the  2.6.35 14, 16, and 17 kernels all screw up on the screen.
[19:45] <Sarvatt> hmm last response is saying the maverick kernel works fine for someone else with your same laptop, thats odd
[19:47] <penguin42> Sarvatt: And same panel? I think the panels vary on the same models
[19:48] <jg> Sarvatt: there are two slightly different chips under the same model, much less what panel it mayhave.
[19:48] <micahg> any chance of getting the intel 2.12 driver in the x-updates PPA?
[19:48] <micahg> for Lucid that is
[19:49] <jg> Sarvatt: actually, four flavors depending on what configuration: ntel® Core™ i7-620M Processor (2.66 GHz, 4 MB L3 cache)
[19:49] <jg> Intel® Core™ i5-540M Processor (2.53 GHz, 3 MB L3 cache)
[19:49] <jg> Intel® Core™ i5-520M Processor (2.40 GHz, 3 MB L3 cache)
[19:49] <jg> Intel® Core™ i7-640LM Processor (2.13 GHz, 4 MB L3 cache)
[19:50] <Sarvatt> micahg: I haven't put it in yet because it requires libdrm 2.4.21 which will break nouveau but will eventually
[19:50] <Sarvatt> LM does have a different GPU than the M models
[19:50] <micahg> Sarvatt: k, thanks, will wait in anticipation :)
[19:51] <penguin42> and all of those are the in-socket gpu aren't they?
[19:51] <Sarvatt> yeah gpu is on the same package as the cpu
[19:52] <Sarvatt> the LM models have a lower clocked gpu that turbo boosts higher and are about half the speed since turbo boost is pretty useless on the gpu :D
[19:53] <penguin42> oh what a weird way of doing it
[19:53] <Sarvatt> support for turbo boost didnt go in until 2.6.36 but its backported into 2.6.35-17 in maverick
[19:54] <penguin42> I think Turbo boost on the CPU worked on Lucid didn't it?
[19:54]  * penguin42 has i7-860
[19:54] <jg> I gotta run....
[19:55] <Sarvatt> jg: sorry again I don't have any more info for ya, will ask jbarnes if any of this eDP stuff queued in drm-intel-next might fix it
[19:58] <Sarvatt> penguin42: I dunno, maybe the cpu turbo boost can happen automatically but the GPU definitely can't, there's an intel_ips module controlling it now
[19:58] <penguin42> ok
[20:01] <Sarvatt> theres a description of it here - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=aa7ffc01d254c91a36bf854d57a14049c6134c72
[20:03] <penguin42> ah yeh, gpu is separate
[20:03] <penguin42> getting the CPU/GPU trade off is probably a non-trivial (non-soluble?) problem
[20:05] <penguin42> anyway, time to disappear until next weekend
[20:21] <Sarvatt> it only clocks up the gpu when theres enough power headroom for it to do so which is pretty much only when the cpu isn't getting used, and how often do you really need gpu power without a big cpu load going on at the same time? :D so those LM/UM core 2010's are massively crippled since they run at 1/2-1/4 the speed without turboboost
[21:43] <Sarvatt> linux-headers-generic-lts-backport needs to somehow get pulled in for people using linux-image-foo-lts-backport metapackages..
[21:43] <Sarvatt> for nvidia/fglrx sorry
[21:43] <tjaalton> isn't linux-foo-lts-backport for that?
[21:44] <Sarvatt> it only grabs the kernel, blobs just silently fail because theres no headers
[21:44] <Sarvatt> then again maybe neither work with it anyway, I didn't check :)
[21:44] <tjaalton> right, only depends on the image, meh
[21:45] <Sarvatt> oh hp, your crappy windows specific bioses never cease to amaze me
[21:46] <Sarvatt> i have to boot this pavilion with a geforce 6150 IGP on battery for powermizer to work
[21:48] <tjaalton> heh
[21:51] <Sarvatt> great, it never goes up from the lowest speed if i do that too. so boot with battery to make it too slow to do anything but saves power or boot off ac and have it suck down 8 watts more idle
[21:53] <Sarvatt> never goes up rather
[23:16] <jg> Sarvatt: it is actually quite easy to issue commands to a GPU that might keep it very busy, without taking much CPU....
[23:17] <jg> Sarvatt: it's very application dependent as to whether it will take much CPU to keep the GPU busy.
[23:22] <Sarvatt> I was looking at it from the perspective of playing a game where there's almost never a low cpu load going on, but even say dragging a window around with compiz enabled pushes the cpu enough where it wouldn't use the turbo boost speed from what I can see
[23:28] <jg> Sarvatt: I gathered from keithp that airlied may have gotten one of these eDP laptops, FWIW.
[23:30] <Sarvatt> looks like he got a 2740p from the commit message on one of his recent patches
[23:30] <jg> I've been too busy with vacation, a workshop, and chasing a problem in the internet to have had time to follow up;
[23:31] <jg> on the other hand, Yellowstone was very pretty indeed, and the internet bug definitely important; maybe I'll have a bit of time now to act as a decent tester....