[06:57] <crevette> hello
[06:57] <tjaalton> so, do we want input-properties in 1.5? :)
[06:57] <tjaalton> *iput-device-
[06:58] <tjaalton> uh, _input_
[06:58] <crevette> what is evdev ? I see this used for keyboard layout in gnome-keyboard-properties
[06:58] <tjaalton> a driver
[06:58] <tjaalton> generic driver for simple input devices
[06:59] <tjaalton> man evdev
[06:59] <crevette> ah okay thanks
[06:59] <crevette> so no need to set a specific keyboard layout now
[06:59] <tjaalton> you must use that model or else things will break
[06:59] <tjaalton> layout != model
[07:00] <crevette> ah sorry, my X knowledge is zip
[07:00] <tjaalton> you can change the layout
[07:00] <tjaalton> the model should probably be forced, but that would break non-evdev setups
[07:01] <crevette> the driver is not listed in xorg.conf, this is not a problem?
[07:01] <tjaalton> no
[07:01] <tjaalton> I probably should upload the xorg changes
[07:01] <crevette> (I regenerated the xorg conf with dpkg-reconfigure recetnly for intrepid)
[07:02] <tjaalton> after the upload you'd have no input devices in xorg.conf
[07:02] <tjaalton> since they are ignored anyway
[07:02] <crevette> I had a strange problem few days back, where I had no input in gdm after an update
[07:02] <tjaalton> mouse worked?
[07:02] <crevette> so I wasn't able to logon :)
[07:03] <crevette> no
[07:03] <crevette> but the problem vanished
[07:03] <tjaalton> so you didn't have all the updates
[07:03] <tjaalton> we use input-hotplug now, and that requires the latest hal
[07:03] <crevette> so blame update-manager :)
[07:03] <crevette> ah, xorg as the hal module now
[07:03] <crevette> great
[07:03] <tjaalton> "few days back" <- what does that mean?
[07:04] <crevette> so we take advantage of hotplug 
[07:04] <crevette> tjaalton: hmmm, less than a week
[07:04] <tjaalton> which mirror?
[07:04] <tjaalton> the hal version was uploaded tuesday last week
[07:04] <crevette> http://archive.ubuntu.com/ubuntu/ 
[07:04] <crevette> perhaps One week, I don't remamber
[07:05] <crevette> remember
[07:05] <crevette> but it disappeared now
[07:06] <tjaalton> ok, you have the old xorg.conf somewhere?
[07:06] <tjaalton> or maybe you didn't have evdev installed
[07:07] <crevette> let's see
[07:08] <crevette> the dpk-reconfigure remove a InputDevice stanza for synaptic
[07:08] <crevette> removed
[07:08] <crevette> and added XkbOptions"	"lv3:ralt_switch
[07:12] <tjaalton> those should not matter
[07:50] <bryce> tjaalton: btw I got all the Gem packages built
[07:50] <bryce> installed and tested them on my laptop too.
[07:51] <tjaalton> bryce: whee, works too?
[07:53] <bryce> well, it isn't broken!
[07:53] <tjaalton> bryce: btw, what do you think about input-device properties? whot would like to see it in 1.5 and I'm pushing for it. It would also need a patch for inputproto and libXi, but would allow changing settings runtime for those devices that support it
[07:53] <bryce> (I don't see any difference... but I assume the kernel side stuff has to be there)
[07:54] <bryce> yes I definitely think that's worth including
[07:54] <tjaalton> bryce: heh, yeah it falls back to the old stuff
[07:54] <tjaalton> cool, I'll prepare stuff for post-alpha4
[07:54] <bryce> great
[07:55] <tjaalton> synaptics support (think SHMConfig madness..) is not there yet, but I believe it's just a matter of time if 1.5 supports IDP
[07:56] <bryce> btw, all the gem stuff has been merged to master upstream 
[07:56] <tjaalton> yep, that's great news
[07:57] <tjaalton> I also looked at plymouth (a kernel-modesetting -aware bootsplash thingie), but that's probably intrepid+1 material by now :)
[07:58] <bryce> what's its dependencies?
[07:58] <tjaalton> it has fallbacks for non-km setups, so it just needs integration
[07:59] <tjaalton> basically would replace usplash once it's mature
[08:02] <crevette> GEM is planned for intrepid or later?
[08:02] <tjaalton> crevette: I guess it depends on how stable it is
[08:03] <tjaalton> or will be
[08:22] <bryce> heya tseliot
[08:23] <bryce> crevette: we're just beginning to test it; hard to say when it'll be ready.  I've got packages if you want to play with it; I'll post to ubuntu-x@ in a bit
[08:23] <tseliot> hi bryce
[08:23] <crevette> bryce: cool
[09:58] <tjaalton> bryce: btw, do you have the source for the versions_current.html script somewhere? I could reuse it for vdr packages
[10:06] <bryce> tjaalton: hmm I take back my "I don't see any difference".  It's quite buggy actually
[10:06] <tjaalton> hehe :)
[10:06] <bryce> had it flashing red screens at me.  quite alarming
[10:13] <bryce> tjaalton: http://bryceharrington.org/files/xorg_pkg_list, http://bryceharrington.org/files/xorg_pkg_list.cron
[10:14] <tjaalton> bryce: cool, thanks!
[10:18] <bryce> wow, I've totally thrashed this laptop
[10:30] <bryce> I think it's because I did an apt-get upgrade after installing the test packages
[10:30] <bryce> silly man I am
[10:30] <tjaalton> :)
[10:31] <tjaalton> things to do when feeling tired :)
[10:32] <bryce> network-manager broke 
[10:32] <bryce> but it's working now
[10:35] <tjaalton> works fine here too, 3G and all
[10:35] <tjaalton> I've got IDP ready, now all I need is drivers that support it :)
[10:36] <tjaalton> evdev checks for input API 3, so it needs patching to work
[10:36] <tjaalton> whot said that synaptics is almost ready
[10:36] <bryce> tjaalton: any ideas on 255008?
[10:37] <tjaalton> bryce: yeah, mdz should change the model in the kbd capplet
[10:37] <tjaalton> bag
[10:37] <tjaalton> uh
[10:37] <tjaalton> *bah
[10:37] <bryce> sounds like he's not satisfied with that
[10:39] <tjaalton> if we decide not to support non-evdev setups, it could be forced in gnome
[10:39] <tjaalton> evdev forces the model initially, but it can be changed AIUI
[10:39] <tjaalton> so the driver could force evdev once and for all
[10:40] <bryce> hm, that doesn't sound like a great solution, since conceivably evdev might not work for some folks
[10:40] <tjaalton> so if you use evdev, the driver forces the model to be evdev?
[10:41] <bryce> hrm, with the gem mesa + libdrm, the gem -intel refuses to build.  hrmph.
[10:41] <bryce> "Unmet build dependencies: libgl1-mesa-dev | libgl-dev"
[10:45] <bryce> ah, need to throw more .deb's at it.  of course.
[10:46] <bryce> sweet it's building
[10:46] <tjaalton> you've got them on ppa?
[10:48] <bryce> no
[10:48] <bryce> hrm, fails to build due to missing uxa.h
[10:48] <jcristau> there's a patch for that on the list
[10:49] <bryce> jcristau: ah, it's not in git?
[10:49] <jcristau> think not
[10:49] <bryce> screen flickers a lot too
[11:13] <bryce> alright, Gem-enabled buggy crap posted to list.  time for bed.  cya.
[11:13] <tjaalton> night :)
[11:14] <soren> "GEM"? Wow, that takes me back.
[11:14]  * soren wonders if even Wikipedia remembers
[11:14] <soren> Oh, it does: http://en.wikipedia.org/wiki/Graphical_Environment_Manager
[11:15] <soren> Oh, it's GPL now!
[11:16] <tjaalton> workbench ftw!
[11:16] <tjaalton> :)
[11:21] <soren> :)
[16:25] <tjaalton> pwnguin: turns out my tablet is a rebranded waltop media tablet
[16:25] <tjaalton> and not really aiptek
[16:25] <tjaalton> http://www.waltop.com/p_mediate_tablet.htm
[16:25] <tjaalton> identical
[16:28] <pwnguin> heh
[16:28] <pwnguin> isn't hardware rebranding fun?
[16:29] <tjaalton> sure is
[16:30] <tjaalton> apparently wacom should work
[16:30] <pwnguin> orly?
[16:30] <tjaalton> at least for the other walto models
[16:30] <tjaalton> waltop
[16:30] <pwnguin> i almost wonder if
[16:30] <pwnguin> walto rebrands other people's stuff
[16:30] <tjaalton> like aiptek 600U and 14000U
[16:30] <tjaalton> could be, but lsusb shows this as waltop
[16:31] <pwnguin> who owns the vendor id?
[16:31] <tjaalton> WALTOP International Corp.
[16:31] <pwnguin> crazy
[16:32] <pwnguin> when i picked up mine, i made sure it was a wacom
[16:32] <pwnguin> specifically to avoid that crap
[16:32] <tjaalton> yeah, talk about luck :)
[16:32] <tjaalton> I only need to verify it works
[16:33] <pwnguin> id be surprised if wacom actually works with it
[16:33] <tjaalton> I knew it was el cheapo model, and if it didn't work I could always sell it without losing that much
[16:33] <pwnguin> linuxwacom is actually run by wacom
[16:34] <tjaalton> maybe it's just rebranded wacom :)
[16:48] <tjaalton> yep, works
[16:49] <pwnguin> crazy
[16:50] <pwnguin> perhaps waltop licensed wacom technology, and aiptek rebranded that
[16:50] <tjaalton> I need to fix the settings, but at least it doesn't jump like with aiptek
[17:03] <tjaalton> even pressure works, yay
[17:14] <soren> Ok, someone please enlighten me:
[17:14] <soren> What are the benefits we get from evdev that justifies making my life miserable?
[17:15] <tjaalton> :/ I guess you mean kvm?
[17:15] <soren> And anything else that cares about extended keycodes, but yes, specifically kvm.
[17:17] <tjaalton> tbh I haven't tried a virtual setup with input-hotplug.. what issues does it have?
[17:18] <soren> The issue is not in the guest. It's the host.
[17:18] <soren> Oh, perhaps that's what you meant.
[17:18] <soren> Anyhow, the problem is..
[17:18] <soren> ..that someone's at the door.
[17:18] <soren> brb
[17:18] <tjaalton> :)
[17:27] <tjaalton> hmm, can't create the kvm img
[17:27] <tjaalton> "next" does nothing
[17:31] <soren> Er... No, it's a bit... no.
[17:34] <soren> tjaalton: Well, to get back to the core issue. What are the benefits we get from evdev?
[17:34] <tjaalton> soren: input-hotplug
[17:35] <tjaalton> and out-of-the-box support for mice with N buttons (N>>3)
[17:35] <tjaalton> etc
[17:36] <soren> Ah, so it's a prerequisite for input-hotplug? that's what I thought.
[17:37] <tjaalton> hal can be taught to load other drivers, too
[17:37] <tjaalton> so if you're thinking of virtual machines, they could load vmmouse AIUI
[17:38] <tjaalton> there just needs to be a way to identify one (from hal)
[17:39] <soren> The problem is with evdev on the host.
[17:39] <tjaalton> if your keys are behaving strangely, make sure to set the keyboard model as evdev
[17:40] <soren> If the host uses evdev, any kind of extended key presses are lost.
[17:40] <bryce> morning
[17:40] <tjaalton> soren: does xev show them?
[17:40] <tjaalton> morning bryce
[17:40] <soren> Like, say, up arrow and down arrow.
[17:41] <tjaalton> soren: as I said, make sure that the model is evdev :)
[17:41] <tjaalton> bug 255008
[17:41] <bryce> tjaalton: maybe we should revert back to non input-hotplug for keyboards?
[17:41] <tjaalton> the real solution would be to make sure that libxklavier uses evdev model when evdev is used
[17:41] <soren> I don't know why, but my laptop screen is *very* dark suddenly, and it doesn't let me increase the brightness, so I'm rebootting. bbiab
[17:41] <tjaalton> bryce: I don't think that's necessary
[17:42] <tjaalton> bryce: see the last message on that bug
[17:42] <tjaalton> by me
[17:45] <tjaalton> to further quote daniels, "gnome stupidity is 99% of the problem."
[17:45] <tjaalton> "makes a pleasant change from us just being too shit."
[17:45] <bryce> hmm.  doesn't sound certain that this would work
[17:46] <tjaalton> why?
[17:48] <bryce> well, first we'd need to backport device properties, then patch libxklavier, etc.  Hopefully/maybe that'd work, but it doesn't sound like a certain solution
[17:48] <bryce> + what other issues might it bring?
[17:48] <tjaalton> less than what forcing it in gconf would
[17:48] <tjaalton> which is the only other way
[17:48] <tjaalton> (aiui)
[17:58] <tjaalton> bryce: svu should be persuaded to fix libxklavier ;)
[18:06] <bryce> tjaalton: I guess I should see if I can reproduce the issue
[18:06] <bryce> but breakfast first... bbiab
[18:07] <pwnguin> is there a doc on the keymap problems i should read?
[18:08] <tjaalton> pwnguin: what do you mean?
[18:08] <pwnguin> my laptop keyboard sucks in intrepid
[18:08] <pwnguin> page down triggers right click
[18:08] <pwnguin> arrow keys dont work
[18:09] <tjaalton> start from that bug
[18:09] <tjaalton> just reset the kb model from the gnome keyboard capplet
[18:09] <tjaalton> it's documented on the alpha4 release notes btw
[18:09] <pwnguin> well, heh
[18:09] <pwnguin> ive been using intrepid since before alpha1
[18:10] <tjaalton> yes, relnotes are not for you ;)
[18:10] <tjaalton> the wacom.fdi doesn't seem to work right, evdev grabs the device
[18:11] <pwnguin> tjaalton: is it too late to pull in a new release from upstream?
[18:11] <pwnguin> oh right, i forgot it might not build
[18:11] <tjaalton> pwnguin: don't think so
[18:11] <pwnguin> our fearless hero danny may have broken linuxwacom on debian in the process of fixing openSuse
[18:12] <tjaalton> heh
[18:12] <pwnguin> of course, it takes a committer to make it official
[18:12] <tjaalton> what good is the kernel module for?
[18:12] <pwnguin> i have no clue
[18:12] <tjaalton> doesn't look like it's using it for me
[18:13] <tjaalton> but it seems to work fine
[18:13] <pwnguin> i dont see it either
[18:13] <tjaalton> the modules is loaded, just that lsmod shows that nothing is using it
[18:14] <pwnguin> its not even loaded in mine
[18:15] <tjaalton> I should probably wash my bike while I have time.. bbl->
[18:15] <pwnguin> tjaalton: thanks for the keyboard tip
[18:23] <pwnguin> oh thats not good
[18:23] <pwnguin> dmesg | grep wacom
[18:23] <pwnguin> [   50.383182] Xorg[7733]: segfault at ff36 ip b68a97cc sp bfc034d0 error 4 in wacom_drv.so[b68a6000+13000
[18:25] <bryce> tjaalton: what are the issues from forcing it in gconf?  that sounds more feasible to do for alpha-4 - what if we deployed that for alpha-4 and switched back once the libxklavier fixes are available?
[20:21] <bryce> tjaalton: what are the issues from forcing it in gconf?  that sounds more feasible to do for alpha-4 - what if we deployed that for alpha-4 and switched back once the libxklavier fixes are available?
[20:21] <bryce> oops mispaste
[21:26] <tjaalton> bryce: AIUI it would break those setups that don't want to run with evdev
[21:26] <tjaalton> I didn't think that this should be fixed for alpha4
[21:46] <bryce> tjaalton: why not?
[21:47] <tjaalton> lack of time? :)
[21:53] <tjaalton> hmm, actually, forcing the key /desktop/gnome/peripherals/keyboard/kbd/model as empty would use whatever the system has as default
[21:53] <tjaalton> so there's no need to force it as evdev
[21:54] <tjaalton> I'll test this sucker on my laptop..
[21:55] <seb128> tjaalton: the default is empty already
[21:55] <tjaalton> seb128: yes, but not mandatory
[21:55] <seb128> tjaalton: it's set according to the xorg value during the first login most likely
[21:55] <seb128> tjaalton: we don't force configs this way over users
[21:56] <tjaalton> seb128: btw, you like hacking libxklavier? :)
[21:56] <seb128> no
[21:56] <tjaalton> heh
[21:56] <seb128> I've no clue about keyboards
[21:57] <tjaalton> are there any packages that set mandatory gconf keys?
[21:58] <tjaalton> seb128: the problem is that there's no other way, at least for alpha4
[21:59] <seb128> tjaalton: no, setting mandatory gconf keys is wrong
[21:59] <seb128> that's a sysadmin thing
[22:00] <seb128> the package should not touch this database
[22:00] <seb128> that's likely changing users value
[22:00] <seb128> you might think it's a good idea in some case but that's wrong and you will get some angry users
[22:00] <tjaalton> how so? it's not copied to the user settings
[22:01] <tjaalton> we'll get angry users who have broken keyboard
[22:01] <seb128> no, but mandatory is something sysadmin set usually
[22:01] <seb128> so if you overwrite their changes that's not good
[22:01] <seb128> that's something the distro should not touch
[22:01] <seb128> well, overwritting sysadmin configs is not the way to do that
[22:01] <tjaalton> ok
[22:02] <seb128> if you want to force a value change the code which reads the key, don't do system changes
[22:02] <tjaalton> hmm
[22:03] <tjaalton> what might that be
[22:03] <seb128> tjaalton: gnome-settings-daemon
[22:04] <tjaalton> seb128: btw, the multimedia-keybindings are still wrong ;)
[22:04] <seb128> tjaalton: http://cvs.fedoraproject.org/viewcvs/rpms/gnome-settings-daemon/devel/gnome-settings-daemon-2.21.91-ignore-model-if-evdev.patch
[22:04] <tjaalton> seb128: cool!
[22:04] <seb128> tjaalton: I'll update the package to change those and apply this patch too
[22:04] <seb128> doing that in a few minutes
[22:05]  * tjaalton hugs seb128 <3
[22:05]  * seb128 hugs tjaalton
[22:05] <tjaalton> much easier than doing it in libxklavier
[22:05] <seb128> tjaalton: do you have a bug number about the issue?
[22:05] <tjaalton> bug 255008
[22:05] <tjaalton> I'll reassign against g-s-d
[22:06] <tjaalton> (the libxklavier part)
[22:06] <seb128> ok, thanks
[22:06] <seb128> I'll will close it in the changelog ;-)
[22:08] <tjaalton> eeexcellent..</burns>
[22:14] <tjaalton> fedora has had this patch for nearly three months.. shame on them. it should be upstream
[22:15] <bryce> cool, thanks seb128
[22:16] <tjaalton> hmm, the patch is over five months old
[22:20] <seb128> tjaalton: right, I'll upstream it now
[22:20] <tjaalton> seb128: great, thanks
[22:20] <seb128> I mean send it to bugzilla.gnome.org
[22:20] <tjaalton> yep
[22:31] <seb128> tjaalton: bug open upstream and change uploaded to intrepid
[22:34] <tjaalton> seb128: rrrock
[22:35] <tjaalton> trying to figure out what's wrong with 10-wacom.fdi
[23:25] <superm1> bryce, on one of our platforms with cantiga graphics we were seeing this odd situation where it looks like too many displays are enabled at one time.  kinda like the panels are restricted to the maximum output of the second display (which isn't physically plugged in).  Jose said there was a patch at some point in 8.04 to work around this behavior.  is it possible that such patch didn't make it into intrepid?
[23:28] <bryce> hi superm1
[23:28] <superm1> hi :)
[23:29] <bryce> ah sounds like our old pipe-a quirk issue
[23:29] <superm1> was the quirk hardware specific?
[23:30] <superm1> or generic to the whole intel driver
[23:30] <bryce> er, I mean the ignore_tv quirk
[23:30] <superm1> well this must be an evolution of it then..
[23:30] <bryce> yeah that's the problem - they're tied to specific hardware pci id's
[23:31] <superm1> no svid on these, hdmi probably would be the culprit to be causing it
[23:31] <bryce> a lot of the dell systems have the issue, and we just quirk each of them as we identify it.  So probably we just need to do the same.
[23:31] <superm1> i'll be getting later engineering builds very soon for  these too, so i'll check with those first
[23:32] <bryce> put in a bug with the lspci -nnvv output and I'll take care of it.  I can usually backport the quirks easy if you want it fixed in hardy too
[23:32] <superm1> do you know if this sort of thing is caused by a vbios bug then?  we can get ahead of the curve if so and report these types of issues
[23:33] <bryce> I don't know the specifics... keithp or jesse would be the ones to ask.  I understood the problem was that they can't detect loads on tv_out
[23:33] <superm1> to bios teams etc
[23:34] <bryce> I need to doublecheck some of the rework they've done to the quirks.  I know they've changed some to affect whole classes, so that might take care of it.  Not sure.
[23:34] <superm1> that seems odd that a load is not detectable on tv out.  how else would it dynamically determine in the bios what displays to turn on
[23:34] <superm1> okay well i'll sync back up with you once the later build gets here
[23:34] <bryce> ok cool
[23:34] <superm1> would you like one of these to play with too?
[23:34] <bryce> sure
[23:34] <superm1> i'm not sure if you have anything with cantiga thus far
[23:35] <superm1> okay i'll check with the quantities that we have and see what i can do :)
[23:35] <bryce> I did have one briefly a month or so ago, and sorted out a kernel issue they were having
[23:35] <bryce> but I only had it for about a week and didn't get into much depth in the testing beyond that, and a totem issue
[23:38] <superm1> okay we've got plenty of these with more builds coming in soon.  you can hang on to this one for a  bit then at least 
[23:38] <bryce> excellent
[23:39] <superm1> re that radeonhd thing i was talking about the other day, it shows up on the new engineering builds too.  vesa is okay with it, so i'm leaning towards buggy radeon driver
[23:39] <superm1> so i'll get both these out in the mail tomorrow or so
[23:39] <bryce> btw, if you're interested I've put up some GEM-enabled packages of -intel, mesa, and libdrm at http://people.ubuntu.com/~bryce/Testing/Gem/
[23:39] <superm1> what's GEM?
[23:39] <bryce> it's the new graphics memory manager (to replace TTM)
[23:40] <bryce> that in theory makes X all manner of happy
[23:40] <superm1> ah
[23:40] <superm1> sure i'll add a note to take a look
[23:40] <superm1> should be valid on all variants of -intel?
[23:40] <bryce> it just got merged into master upstream, so figured we ought to have packages for anyone wishing to start playing with it
[23:41] <superm1> ah so sorta like an intel-next type of thing to play with then
[23:41] <bryce> I believe so.  Or at least all 9xx chips
[23:42] <bryce> yeah, I stuck it on my 965 and found it to be quite buggy (bad flickering).  So definitely still a WIP