[00:29] <pwnguin> huh, neat wiki page
[00:29] <pwnguin> i was just building kernel.org git and wondering what half the crap was
[00:29] <pwnguin> PAT is in .25 as "experimental" i think
[00:30] <bryce> pwnguin: :-)
[00:30] <pwnguin> most of it i left off because its been ages since i built my own kernel and i just wanted to turn on a simple debug option for MMC
[00:32] <bryce> mmm, I can reproduce the "picks vesa instead of ati" bug
[00:33] <pwnguin> how DOES x pick which driver to include?
[00:34] <bryce> indeed, something I want to understand more deeply
[00:35] <bryce> until now I had *thought* it was based on pci id's, but this particular card I'd tested on another mboard with no probs
[00:36] <pwnguin> id just like to see how hard it is to change it from nv to nouveau on my machine
[00:36] <bryce> pwnguin: is it not listening to what you specify in xorg.conf?
[00:36] <pwnguin> it is
[00:37] <pwnguin> but theres a small chance the nouveau package could set it up by default ;
[00:37] <pwnguin> )
[00:38] <pwnguin> is dexconf encouraged?
[00:38] <bryce> we're trying to move away from using that
[00:38] <pwnguin> thats what i thought
[00:39] <pwnguin> there's a small thread on a wacom bug about the removal of wacom from the default xorg (and the removal of xorg.conf itself)
[00:39] <pwnguin> and somehow dexconf came up
[00:39] <bryce> yep, I know that one
[00:39] <pwnguin> meanwhile, i think wacom upstream supports autodetection or something
[00:40] <bryce> requires input hotplug
[00:41] <pwnguin> hmm
[02:47] <bryce> tjaalton: do we still need to be updating discover-data?  That's obsolete now as far as we're concerned, isn't it?
[05:37] <tjaalton> bryce: right, no need for it now
[05:37] <tjaalton> anymore
[05:43] <bryce> ok
[16:32] <seb128> bah, the xrandr capplet still has issues
[16:33] <seb128> hum, I reassigned a bug about a similar issue to xorg some days ago I think I can't find it now
[16:34] <seb128> I can't enable 2 screens using it on my laptop
[16:34] <seb128> some user comments that he had to tweak the xorg.conf to allow a virtual desktop going to 3000 or something, does something knows where the bug has been reassigned? ;-)
[16:49] <seb128> bryce: around?
[17:55] <bryce> yes
[18:10] <seb128> bryce: any idea about my question? I've the same issue on D630, no way to enable the laptop and an external screen together
[18:20] <tjaalton> seb128: even clone mode doesn't work?
[18:26] <seb128_> re
[18:27] <tjaalton> seb128: so not even clone mode works?
[18:27] <seb128_> trying, I just plugged the screen on my laptop again
[18:27] <bryce> seb128: right, to allow for >2048x2048 you must set the Virtual line in xorg.conf
[18:27] <seb128_> that's the warning I get
[18:28] <seb128_> rw_crtc_set_config: assertion `x + mode->width <= info->max_width' failed
[18:28] <seb128_> the clone mode "works"
[18:29] <seb128_> it tries to activate both screens but the external monitor displays a out of sync
[18:29] <seb128_> where it's a 19" lcd which should handle easily the 1024x768 60Hz selected
[18:30] <seb128_> bryce: could we bump this limitation? because that means almost nobody will get the 2 screens mode working right now
[18:30] <seb128_> I doubt many people use < 1024 
[18:30] <bryce> no, it's a hard limit
[18:30] <seb128_> "hard"?
[18:30] <seb128_> that's not closed source code, is it?
[18:31] <bryce> hard == requires a bunch of new kernel code
[18:31] <seb128_> I mean we can change the code and rebuild no?
[18:31] <bryce> no
[18:31] <seb128_> urg
[18:31] <bryce> hardware limit
[18:31] <bryce> the hardware has a fixed framebuffer size which varies from card to card but is typically 2048x2048
[18:31] <seb128_> in the bug I read this week the guy said he was using a virtual size in the xorg.conf and that was working for him I think
[18:31] <jcristau> bryce: not really
[18:32] <seb128_> I start thinking using this capplet is an error
[18:32] <seb128_> dual screen doesn't work due to hardware limitations
[18:32] <jcristau> the problem with > 2048x2048 on intel is that you don't get any acceleration
[18:32] <seb128_> lot of drivers are buggy when using xrandr
[18:32] <jcristau> in < i965 i mean
[18:34] <bryce> jcristau: well, there's still a hardware limit for 2D, although it's up around 8k.  But the point is that the limit is not just a #define we can tweak without consequence
[18:34] <jcristau> bryce: 8k is plenty though :)
[18:34] <bryce> seb128, yeah I agree, I sort of wish we'd just gone back to manual configuration
[18:36] <jcristau> the bigger problem right now imo is that the framebuffer can't be resized at runtime
[18:36] <seb128_> ok, enabling 2 screens doesn't work even when under the 2048 limit
[18:36] <jcristau> seb128_: i suppose 'xrandr --auto' on the command line doesn't help?
[18:37] <jcristau> seb128_: the limit isn't 2048, it's whatever was allocated at server startup based on the connected outputs at the time
[18:37] <seb128_> hum, weird
[18:38] <seb128_> xrandr --auto activates the 2 screens, they have the same image though so I guess that's the equivalent of the clone mode in the capplet
[18:38] <seb128_> though they don't have the same resolution
[18:44] <seb128_> xrandr --properties lists 1 screen
[18:44] <seb128_> and LVDS and TMDS-1 being connected
[18:45] <jcristau> can you paste the output?
[18:48] <seb128_> jcristau: http://people.ubuntu.com/~seb128/xrandr
[18:48] <bryce> weird, why's it spitting out edid data?
[18:48] <jcristau> bryce: because the edid is a randr property
[18:48] <jcristau> so xrandr --prop shows that
[18:49] <seb128_> so xrandr --auto works better than this whole capplet thing which doesn't manage to enable both screens together
[18:50] <jcristau> seb128_: so, it looks like your laptop has a 1440x900 panel; which means that the server allocated a 1440x1440 fb (so you can rotate the panel)
[18:50] <seb128_> correct
[18:53] <jcristau> and now the fb can't be resized, so you're stuck with both monitors showing basically the same thing (except each has some part of the desktop which not on the other one :))
[18:53] <jcristau> that's the expected result right now, when you don't force the fb size in xorg.conf
[18:54] <seb128_> right
[18:54] <seb128_> the common part is correctly displayed
[18:54] <seb128_> the other portions are in a weird state
[18:54] <seb128_> like not refreshed or something
[18:55] <jcristau> hmm
[18:57] <seb128> and compiz seems to not like the xrandr resolution changes
[18:58] <jcristau> bad compiz
[19:25] <bryce> seb128: is that problem with intel or ati graphics?
[19:26] <seb128> intel 965
[19:26]  * bryce nods
[19:26] <bryce> I know what you're describing, I've seen that as well
[19:27] <bryce> did restarting the window manager make it go away?
[19:28] <seb128> I restarted the session