=== BUGabundo is now known as BUGa_vacations
[00:43] <bryceh> RAOF, I'm going through the queue of bugs that have been nominated for lucid and assigning them out to people, so I'm going to assign a few -intel bugs to you
[00:44] <RAOF> Sounds good to me.
[00:44] <bryceh> RAOF, but the way we handle these at this stage in the release is that they need *reviewed* more than fixed
[00:44] <bryceh> look at them and decide if they look doable and worthwhile to fix for lucid - if not, unassign yourself and mark them 'ct-rev'
[00:44] <bryceh> if they do look important, forward them upstream (or find a patch to fix them)
[00:45] <RAOF> :)
[00:45] <bryceh> keep in mind we can also fix some post-release via SRUs
[00:45] <bryceh> ones that are going to affect people from booting the livecd will be higher priority since sru's won't be of help there
[00:45] <RAOF> I can track those by milestoning them to lucid-updates, right?
[00:47] <bryceh> I think so, yes
[00:48] <bryceh> haha, looks like when there is a nomination proposed for karmic, if no one declined or accepted it, launchpad makes a new nomination proposal for lucid even if no one actually asked for it
[00:48] <bryceh> this explains why I'm having to decline like 80% of the nominations :-)
[00:49] <RAOF> :)
[01:47] <jg> bryceh: I tried installing lucid beta 1 on this dell latitude xt I have, and X doesn't start...  Any chance in beta 2?
[01:48] <RAOF> What video does the dell have?
[01:48] <jg> it's a ATI Radeon Xpress 1250, I believe.
[01:53] <jg> RAOF: worked ok in koala...
[01:54] <RAOF> Hm.  I'm not aware of any particular problems with that chip.
[01:54] <RAOF> It's difficult to say anything without logs; Xorg.0.log & dmesg are the favourites.
[01:56] <jg> RAOF: if I can get to the logs.... 
[01:56] <RAOF> Always the problem! :)
[01:56] <jg> particularly with a fresh installation....
[01:57] <jg> and as I had to start over since the upgrade had gone sour from a dying disk...
[01:57] <RAOF> :(
[01:57] <bryceh> jg, new thing for ati this release is we're doing KMS by default
[01:57] <RAOF> You can always try adding radeon.modeset=0 to the kernel boot line.
[01:57] <bryceh> jg, so you could try going ... yeah what RAOF said :-)
[01:58] <jg> bryceh, RAOF: I'll try that in the morning.
[02:37] <johanbr> isn't Xpress 1250 closely related to Xpress 200M?
[02:38] <johanbr> you may also want to try "pci=nomsi" as a kernel parameter
[02:39] <johanbr> see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/509273
[02:39] <ubottu> Launchpad bug 509273 in linux "[Lucid] Radeon Xpress 200M needs PCI quirk to fix or disable MSI" [High,In progress]
[02:42] <bryceh> johanbr, yeah you might be right
[03:08] <Sarvatt> jg: thats a rough one because it has a super rare GPU, i dont think it's working at the moment
[03:09] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati?field.searchtext=rs600
[03:11] <Sarvatt> jg: http://bugs.freedesktop.org/show_bug.cgi?id=25408
[03:11] <ubottu> Freedesktop bug 25408 in DRM/Radeon "Radeon KMS doesn't work for RS600" [Major,Reopened]
[03:33] <jg> Sarvatt, ubottu: certainly seems the same bug
[03:35] <jg> Sarvatt, ubottu: should I add a "mee tooo" to the bug?
[03:54]  * Sarvatt wants a fdo-bug command
[03:59] <bjsnider> is the latest nvidia-settings package going to be added or is it going to be the one in the archive now?
[04:09] <superm1> bjsnider, what changed between the two?  new features, or just bug fixes?
[04:12] <Sarvatt> bjsnider: nvidia-settings 195.36.08 IS 195.36.15
[04:14] <RAOF> Sarvatt: That IOMMU bug doesn't affect me; either with VT on or VT off.  It's possible that it doesn't affect the x200s BIOS', or that I've got a new (or old) enough BIOS to be unaffected.  Or, it's fixed in 2.6.33, but that doesn't seem right.
[04:14] <Sarvatt> RAOF: we dont have DMAR enabled
[04:14] <Sarvatt> i was off
[04:14] <RAOF> Ah, ok.  Cool, false alarm.
[04:18] <Sarvatt> programmable EC = I think I found my next laptop :)
[04:19] <RAOF> EC+
[04:19] <RAOF> EC?
[04:30] <Sarvatt> wow, first time i've seen a bios *that* crappy
[04:31] <Sarvatt> dug up an old dell vostro 200 out of storage and apparently you can't boot syslinux based stuff on it
[04:32] <RAOF> Ah, intel-agp.  The gift that keeps on racing.
[05:08] <bryceh> does lp #546871 look like a DMAR bug?
[05:08] <ubottu> Launchpad bug 546871 in xserver-xorg-video-intel "[i945gm] System freeze induced by Chrome" [Undecided,Confirmed] https://launchpad.net/bugs/546871
[05:09] <bryceh> maybe not
[05:10] <RAOF> There doesn't seem to be any DMAR messages in dmesg, and that doesn't seem to be the symptom (which seems to be a freeze soon after starting X)
[05:13] <bryceh> hmm, well I'm not seeing any LP bugs that match up with the DMAR bug
[05:13] <bryceh> maybe there's something filed against the kernel
[05:15] <RAOF> Sarvatt says we don't actually have DMAR enabled.
[05:22] <bryceh> RAOF, aha
[05:23]  * bryceh un-gtg's a todo :-)
[05:25] <RAOF> Damnit, apple.  What have you done to the macbook such that a perfectly acceptable G96 doesn't boot right?
[06:56]  * bryceh waves to ara
[06:56] <ara> morning bryceh :)
[07:33] <ricotz> Sarvatt, hello, you need to trigger a xserver rebuild in order to get it built against the new x11proto packages
[08:36] <bryceh> Sarvatt, RAOF:  http://www2.bryceharrington.org:8080/X/Graphs/drivers.svg
[09:34] <hceylan> Hello I am trying the packages from ppa:xorg-edgers I upgraded the packages and installed nouveau-back-ports but I get "KMS not enabled" any ideas
[09:34] <hceylan> My main objective is to test nouveau+galliğum3D
[09:49] <RAOF> hceylan: What Ubuntu version are you using?  I think that xorg-edgers is very much tailored to lucid right now.
[09:52] <bryceh> good god -intel is a buggy driver
[09:52] <hceylan> lucid
[09:54] <Ng> bryceh: it's a shame it's not maintained by the creators of the chipset so they can make it really good ;)
[09:55] <bryceh> Ng, *sigh*
[09:56] <RAOF> hceylan: There's all sorts of problems that could be.  Can you pastebin dmesg & Xorg.0.log?
[09:56] <bryceh> Ng, I spent the past month focusing on -ati and have gotten spoiled
[09:56] <Ng> bryceh: oh? is their stuff good now?
[09:57] <bryceh> Ng, well, they seem to be much more sane in how they handle bugs
[09:57] <hceylan> RAOF: gotta go for a meeting I'll be back later. thx
[09:59] <bryceh> Ng, btw how's your -intel experience been lately?
[10:01] <Ng> bryceh: apart from the weird flashing bug going round gm45 people, pretty much solid :)
[10:01] <bryceh> well that's good
[10:01] <bryceh> Ng, have a lp# on the flashing bug?
[10:02] <Ng> bryceh: bug #538648
[10:02] <ubottu> Launchpad bug 538648 in xserver-xorg-video-intel "[gm45] Irregular sync flashes with compiz on (Lenovo T500)" [Medium,Incomplete] https://launchpad.net/bugs/538648
[10:02] <bryceh> ok
[10:03] <Ng> it was happening a lot last night so I rebooted with the i915.powersave=0 suggestion, but I'll need to run it for a few days to be able to say whether it's made any difference. Some days I don't get it at all, some days it happens most minutes
[10:03] <Ng> but never when I have my second monitor attached at work, otherwise I'd be smashing my laptop against a rock ;)
[10:04] <bryceh> :-/
[10:04] <seb128> intel works fine there as long as you don't play with a dock station
[10:04] <seb128> if you start docking and undocking a laptop things just break
[10:05] <seb128> displays don't activate when they should, xorg crashes, etc
[10:08] <Ng> interesting
[10:09] <Ng> I wonder how docking differs from just plugging in a monitor
[10:09] <Ng> I hook up a monitor to DisplayPort via a DVI adapter every day and poke Fn-F7 and it's been very reliable
[10:09] <seb128> well I tend to close the lid while docked
[10:09] <seb128> suspend and take the laptop
[10:09] <seb128> and open it later somewhere else
[10:10] <bryceh> seb128, is it messing up gnome-display-properties, or X in general ?
[10:10] <seb128> which leads to have the laptop screen still off
[10:10] <seb128> bryceh, in the scenario I describe I've no active screen
[10:10] <seb128> so I need to switch vt to get one
[10:11] <seb128> also user switch when docked = fail
[10:11] <seb128> it turns off the external screen
[10:11] <seb128> and I've no way to reactivate it
[10:11] <seb128> I though for a while that the box was crashing
[10:11] <seb128> until I opened the lid of the docked laptop to notice the laptop screen works
[10:11] <Ng> seb128: ah right, I'm quite cautious about doing things while it's suspended, so I unplug everything, poke Fn-F7 and then close the lid :/
[10:11] <Ng> I'll try suspending first :)
[10:12] <seb128> fn-n7 doesn't success to activate the external screen again after user switch
[10:12] <bryceh> good god -intel is a buggy driver
[10:12] <seb128> I need to restart xorg to have it working again
[10:12] <bryceh> http://www2.bryceharrington.org:8080/X/Graphs/drivers.svg
[10:13] <seb128> urg
[10:13] <seb128> nice drop in the ati count
[10:14] <bryceh> it's at least going in the right direction
[10:14] <seb128> right
[10:14] <seb128> I'm wondering if intel is that buggy
[10:14] <seb128> or if there is just a lot of bug noise or users running into the same issues there
[10:14] <tjaalton> yeah it could be the same bugs all over again
[10:15] <bryceh> maybe
[10:15] <bryceh> we do pretty good triaging on -intel though...
[10:15] <tjaalton> true
[10:15] <bryceh> I could buy that on -nvidia which we largely ignore
[10:16] <seb128> I'm not so sure what videocard I should look at in my next laptop now
[10:16] <bryceh> seb128, I recommend not getting a video card
[10:16] <tjaalton> hehe
[10:16] <seb128> lol
[10:16] <tjaalton> headless laptops ftw
[10:16] <bryceh> seb128, seriously, they make your laptop unstable
[10:17] <tjaalton> a braille "display" for your thumb
[10:17] <tjaalton> and then just type away ;)
[10:17] <seb128> let's get a good old serial vt
[10:18] <bryceh> 965 seems to be ok
[10:18] <bryceh> ati 5xx is ok but you can't find those on laptops
[10:19] <seb128> 965 is what I have now
[10:19] <seb128> which I'm fairly happy with out of docking issues ;-)
[10:20] <bryceh> at least with intel they put out fixes fairly routinely, so even if it's broken now, it'll improve next go around
[10:20] <tjaalton> yeah mine works as well, but I don't use another displays
[10:20] <bryceh> of course, the go-around after that all bets are off
[10:20] <tjaalton> -an
[10:20] <bryceh> ati gets better over time
[10:21] <tjaalton> my next laptop will be a lenovo again, so it's likely with intel gfx. the desktop will get ati next
[10:22] <bryceh> ati seems to have performance and corruption issues, but less of the crash/freeze issues
[10:22] <bryceh> intel is the opposite
[10:22] <bryceh> nvidia is just mad
[10:24] <tseliot> heh
[10:26] <bryceh> at least with -nvidia you're in good company
[10:26] <bryceh> and if you don't like being in good company you have the option of -nouveau
[10:28]  * tseliot nods
[10:31] <bryceh> heya tseliot
[10:31] <tseliot> hey bryceh
[10:32] <bryceh> tseliot, btw I've assigned a few bugs to you but don't feel they all need to be solved... just review and decide if they really need attention for lucid; if not, tag them 'ct-rev' and unsub from them.
[10:32] <bryceh> (and if they're kernel issues, please reassign to 'linux')
[10:34] <tseliot> bryceh: that's fine. I think I can bug upstream about some of those bugs and fix the issues if they are in the packaging
[10:34] <bryceh> cool
[10:36] <bryceh> http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
[10:36] <bryceh> good news is we're continuing our downward trend
[10:37] <sebner> tseliot: is there still a nvidia update planned? (You know, I once told you that my performance dropped with the driver upload before the last one)
[10:37] <bryceh> ^ the above graph excludes bugs sent upstream or waiting on users (Incomplete without response).
[10:38] <tseliot> sebner: only minor packaging fixes will get in, unless Nvidia releases something that fixes other bugs
[10:38] <sebner> tseliot: grrrrm kthx
[10:39] <tseliot> sorry but I doesn't depend on me
[10:40] <sebner> tseliot: heh, sure. I'm definately not angry with you but nvidia ;)
[10:44] <bryceh> night
[10:48] <tseliot> good night bryceh
[10:49] <tjaalton> night bryceh 
[10:49] <tjaalton> ok, waltop wacom hotplug works, now to merge the kernel driver
=== kdelogger is now known as apachelogger
[13:28] <apw> anyone know if it is possible to reneble a DRM output which is forced off in a video=foo:d specifier?  from X as it were?
[13:29] <tjaalton> xrandr --auto?
[13:31] <apw> tjaalton, doesn't seem to do anything no
[13:31] <apw> trying to work out just how to handle the booting with screen closed mess
[13:31] <apw> and trying out the video= to try and fix it
[13:33] <tjaalton> hmm ok, maybe xrandr can't help if it's forced off from the cmdline
[13:33] <tjaalton> which probably means the driver can't see it at all
[13:34] <apw> tjaalton, its listed as disconnected
[13:34] <apw> but i don't seem to be able to undo that
[13:34] <apw> which is a shame
[13:35] <tjaalton> ah, ok
[13:57] <bjsnider> tseliot, are you planning on updating nvidia-settings to the latest tarball?
[13:58] <tseliot> bjsnider: I uploaded a fix so that it can work with legacy drivers (no more issues with the lack of the noscanout property). Do you know if there's anything useful in the new release?
[13:59] <bjsnider> i don't know that, but i asked because i have it in the ppa, and users who are upgrading are keeping it because i guess apt is choosing it over the lucid package
[14:00] <bjsnider> i have to add conflicts: screen-resolution-extra (>= 0.13) or whatever to force it out i suppose
[14:01] <bjsnider> it didn't occur to me that apt would keep karmic packages during a distro upgrade
[14:02] <bjsnider> it's possible that someone upgrading from hardy to lucid would still have hardy packages afterwards
[14:03] <bjsnider> !info screen-resolution-extra lucid
[14:03] <ubottu> screen-resolution-extra (source: screen-resolution-extra): Extension for the GNOME screen resolution applet. In component main, is optional. Version 0.13 (lucid), package size 13 kB, installed size 172 kB
[14:07] <tseliot> yes, well if the version in your ppa is greater than the one in lucid, that's expected
=== jg_ is now known as jg
[14:29] <jg> bryceh, RAOF: booting the live cd nokms works.
[15:45] <Sarvatt> seb128: funny enough problems like you describe are usually fixed by bios updates, might be worth looking into
[15:47] <seb128> Sarvatt, oh, thank you
[15:48] <Sarvatt> I just looked up pitti's D430 after seeing he was 10 updates behind and they fixed a similar issue on his
[15:49] <Sarvatt> seb128: what model is it?
[15:51] <seb128> Sarvatt, the laptop? dell d630
[15:59] <Sarvatt> seb128: what bios version are at? it's up to A17 now, I bet you're at A00 too :D looks like all the same upgrades from pitti's d430 are also on this d630, hangs on resume, crashing opening and closing the lid too fast, bios A12 updated the video bios too
[15:59] <Sarvatt> dell site is taking way too long to go through every changelog, i just looked at the latest 5 updates
[16:00] <seb128> Sarvatt, dunno, how do I know the version?
[16:00] <Sarvatt> sudo dmidecode -t bios
[16:00] <seb128> out of looking at the screen on boot
[16:00] <seb128> I never touched the bios in 3 years
[16:00] <seb128> so I bet it's outdated :p
[16:01] <seb128> 	Version: A03
[16:01] <Sarvatt> i mean i only looked between A12 and A17 versions and I saw a ton of major fixes
[16:02] <seb128> I need to look at how you update a bios from linux
[16:02] <seb128> I didn't update bios since I stopped having a dos floppy to do that :p
[16:05] <Sarvatt> yeah same thing here, i just made a freedos boot usb with unetbootin and put the update on it last time though
[16:05] <Sarvatt> i think dell has a bunch of ways to update it in linux
[16:05] <seb128> thanks for the hint
[16:06] <seb128> I will look into trying that
[16:07] <Sarvatt> hmm the firmware-addon-dell package it looks like?
[16:07] <seb128> indeed
[16:08] <Sarvatt> looks like a pain in the butt to set up, freedos boot usb probably much easier :D
[19:30] <apw> bryceh, about?
[19:32] <bryceh> hi apw
[19:33] <apw> bryceh, any idea how to test this multitouch stuff ?
[19:34] <bryceh> apw, heh was gonna ask you the same thing
[19:34] <bryceh> apw, I've got your kernel and my bits on the laptop, and played with gimp a bit
[19:34] <bryceh> doesn't crash, and the finger touches work now (they didn't before)
[19:34] <bryceh> but only for moving the cursor, not for clicking.
[19:35] <bryceh> apw, was hoping the qa team could sketch out a testing process for us
[19:35] <bryceh> apw, know of any tools which will just print out that it received the MT data?
[19:36] <apw> bryceh, mine works ok but only single touch
[19:37] <apw> i am told evtest is the toy, but i can't udnerstand the output
[19:37] <apw> bryceh, i also thought multitouchd was the magic for testing, but i can't make it work
[19:40] <bryceh> no, they decided against using multitouchd, so don't waste time with that
=== Amaranth_ is now known as Amaranth
[19:43] <apw> bryceh, any idea where rafi is?  looking to find out if i need newer firmware
[19:44] <bryceh> apw, haven't seen him on irc for a long while
[19:44] <bryceh> probably reachable via email though
[19:45] <bryceh> just tried evtest, but can't seem to get output out of it when touching screen.  Do I need to make something stop grabbing the events?
[19:50] <bryceh> apw, looks like rafi has a test tool
[19:54] <apw> bryceh, ok i can use evtest to get multitouch data
[19:54] <apw> on mine i have three event channels
[19:54] <bryceh> apw, ok how are you running it?
[19:54] <apw> the one which calls it Multitouch
[19:55] <apw> evtest /dev/input/event13
[19:55] <apw> in my case
[19:56] <bryceh> when I run xinput list I see two 'N-Trig Touchscreen' entries, id=13 and id=14
[19:57] <apw> No i have 3
[19:57] <apw>    name    : "N-Trig Pen"
[19:57] <apw>    name    : "N-Trig MultiTouch"
[19:57] <apw>    name    : "N-Trig Touchscreen"
[19:57] <apw> and its the middle one of those i am using
[19:57] <bryceh> when I run evtest /dev/input/event13 and 14 from within X, and touch the screen, I see nothing printed out
[19:57] <apw> this is all with stock kernel now, as the stuff has gone into lucid
[19:57] <apw> hrm
[19:58] <apw> running as root yes?
[19:58] <bryceh> ok I have two Pens, two erasers, and two touchscreens
[19:58] <apw> hmmm
[19:58] <bryceh> also a generic mouse and a mac mouse button emulation
[19:58] <apw> one pen :)
[19:58] <bryceh> hrm
[19:58] <apw> you do have a different machine of course
[19:58] <bryceh> this is with the kernel in the ppa, not stock lucid
[19:58] <apw> which device id is it?  vendor/product ?
[19:59] <bryceh> I've got the -19 kernel installed, I could boot over to it
[19:59] <apw> that would be the one i am testing on 
[19:59] <bryceh> Dell XT2
[20:00] <apw> sorry i mean what vendor/product does lsinputs list for the touchscreen ones?
[20:00] <bryceh> are you running evtest from under X, or from the console?
[20:00] <apw>    vendor  : 0x1b96
[20:00] <apw>    product : 0x1
[20:00] <apw>  
[20:00] <apw> running sudo evtest ... under an xterm
[20:01] <bryceh> for event13, vendor/product is 0x111d/0x76b2
[20:01] <apw> so thats not an n-trig then
[20:01] <apw> ?
[20:01] <bryceh> it should be
[20:02] <apw> hrm ... 0x111d is something else
[20:02] <bryceh> wait, looks like id's for xinput != id's for lsinput
[20:02] <bryceh> how fun
[20:03] <bryyce> here we go
[20:03] <bryyce> /dev/input/event7
[20:03] <bryyce>    bustype : BUS_USB
[20:03] <bryyce>    vendor  : 0x1b96
[20:03] <bryyce>    product : 0x1
[20:03] <bryyce>    version : 272
[20:03] <bryyce>    name    : "N-Trig Touchscreen"
[20:03] <bryyce>    phys    : "usb-0000:00:1d.1-2/input0"
[20:03] <bryyce>    uniq    : ""
[20:03] <bryyce>    bits ev : EV_SYN EV_KEY EV_ABS EV_MSC
[20:03] <bryyce> that looks better
[20:03] <apw> thats n-trig at least
[20:03] <apw> so next why don't you have a multi-touch like i do ... 
[20:03] <apw> i guess next i'd say get into -19 so we're sure its the same kernel
[20:04] <apw> but i suspect that won't help at all
[20:05] <bryceh> ok one sec
[20:05] <apw> bryceh, ok my 'Touchscreen' event channel does not seem to produce any events
[20:06] <apw> i only get pen events from pen ovviously, and only get finger events on Multitouch
[20:07] <bryyce> ⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
[20:07] <bryyce> ⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ N-Trig Pen eraser                       	id=11	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ N-Trig Pen                              	id=12	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ N-Trig Touchscreen                      	id=13	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ N-Trig Touchscreen                      	id=14	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ N-Trig Pen eraser                       	id=15	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ N-Trig Pen                              	id=16	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ PS/2 Generic Mouse                      	id=18	[slave  pointer  (2)]
[20:07] <bryyce> ⎜   ↳ Macintosh mouse button emulation        	id=19	[slave  pointer  (2)]
[20:07] <bryyce> Linux tytherleigh 2.6.32-19-generic #28-Ubuntu SMP Wed Mar 31 17:46:20 UTC 2010 i686 GNU/Linux
[20:08] <apw> bryyce, what printed that output?
[20:08] <bryyce> apw, xinput list
[20:08] <bryyce> dev/input/event7
[20:08] <bryyce>    bustype : BUS_USB
[20:08] <bryyce>    vendor  : 0x1b96
[20:08] <bryyce>    product : 0x1
[20:08] <bryyce>    version : 272
[20:08] <bryyce>    name    : "N-Trig Pen"
[20:08] <bryyce>    phys    : "usb-0000:00:1d.1-2/input0"
[20:08] <bryyce>    uniq    : ""
[20:09] <bryyce>    bits ev : EV_SYN EV_KEY EV_ABS EV_MSC
[20:09] <bryyce> /dev/input/event8
[20:09] <bryyce>    bustype : BUS_USB
[20:09] <bryyce>    vendor  : 0x1b96
[20:09] <bryyce>    product : 0x1
[20:09] <bryyce>    version : 272
[20:09] <bryyce>    name    : "N-Trig Touchscreen"
[20:09] <bryyce>    phys    : "usb-0000:00:1d.1-2/input0"
[20:09] <bryyce>    uniq    : ""
[20:09] <bryyce>    bits ev : EV_SYN EV_KEY EV_ABS EV_MSC
[20:09] <bryyce> +1 pen, +1 touchscreen
[20:09] <bryyce> still not seeing any multitouch
[20:09] <apw> bryyce, ok so i have a third one
[20:09] <bryyce> hrm
[20:10] <bryyce> bryce@tytherleigh:~$ dmesg | grep -i trig
[20:10] <bryyce> [    2.720204] ntrig 0003:1B96:0001.0001: input,hiddev96,hidraw1: USB HID v1.10 Device [HID 1b96:0001] on usb-0000:00:1d.1-2/input0
[20:10] <bryyce> [    2.727766] ntrig 0003:1B96:0001.0002: input,hiddev97,hidraw2: USB HID v1.10 Device [HID 1b96:0001] on usb-0000:00:1d.1-2/input1
[20:10] <apw> you may have an old firmware
[20:10] <bryyce> apw, have you updated your firmware?
[20:11] <apw> bryyce, nope ... i don't know how
[20:11] <bryyce> heh
=== BUGabundo is now known as BUGa_vacations
[20:15] <bryceh> apw, I'm sure it's something like, "First just boot into Windows 7, then..."
[20:15] <apw> bryceh, i've not booted windows on mine if that helps
[20:15] <apw> but i do think you have to have the latest firmware to get multitouch
[20:16] <apw> so i wouldn't be supprised if its not up to date in there
[20:16] <apw> no idea how one changes it of course
[20:16] <apw> mine is demonstrating two finger tracking, no more than two, and no finger identifiers
[20:16] <bryceh> ok, ...navigating a maze of twisty dell web pages...
[20:16] <apw> but hey ... its doing something
[20:18] <bryceh> ok dunno, but lunchtime.  bbiab
[22:49] <Sarvatt> sheesh, rediculious how many flickering bugs i've googled the laptop name + flicker and seen its a general issue with the model
[22:50] <Sarvatt> like http://www.google.com/search?hl=en&safe=off&q=Dell+Inspiron+1545+flicker
[23:35] <Sarvatt> RAOF: what bios version do you have on your x200s?
[23:35] <RAOF> Sarvatt: Let me fire it up.
[23:35] <Sarvatt> 3 bugs now from people with x200s's that need i915.powersave=0
[23:36] <Sarvatt> one on a T500 too
[23:40] <Sarvatt> RAOF: is it really an x200s? not an x201s or anything?
[23:40] <RAOF> Ok.  You seem to have triggered a bug on my x200s - it's not coming out of suspend at all.
[23:40] <RAOF> Really an x200s.
[23:41] <RAOF> Says so right under the screen.
[23:41] <Sarvatt> whats the last 4 digits of the model underneath?
[23:41] <Sarvatt> like x200s 7401 or something
[23:41] <RAOF> 7465CTO
[23:43] <Sarvatt> sheesh they give you bios update cd's and everything
[23:43] <RAOF> Bios revision 2.8
[23:43] <RAOF> Well, a BIOS update CD isn't really that useful on an x200
[23:43] <Sarvatt> sure it is, usb image creator :D
[23:44] <RAOF> Good point.  Is there a newer bios for me there? :)
[23:44] <Sarvatt> LOTS
[23:44] <Sarvatt> with nice fixes :D
[23:51] <Sarvatt> - Fixed an issue where the computer might hang when the battery was low  - Improved the speed control of cooling fan. - Fixed an issue where VT (Intel virtualization Technology) setting was not changed at the first startup - Fixed an issue where some DVI monitors did not work. - Fixed an issue where 1-3-3-1 beeps might sound at boot or take time to resume normal operation from standby mode. - Fixed an issue that set wrong memory type.
[23:53] <bryceh> Sarvatt, has the bios update confirmed to fix the problems?
[23:53] <bryceh> (my experience has been that bios updates *sound* like they will fix whatever issue I have, but hardly ever actually *do*)
[23:53] <Sarvatt> no i was just asking what he had since he has the same system and doesnt see the problems
[23:54] <bryceh> ahh
[23:54] <Sarvatt> not too much else to go on :D
[23:56] <Sarvatt> RAOF: do you have a dual channel memory setup in that machine? it's a CTO so cant compare
[23:57] <RAOF> Yeah; I've got two dimms in here.