bryce../../src/i830_dri.c: In function 'I830DRISwapContext':00:28
bryce../../src/i830_dri.c:1162: error: 'drm_i915_flip_t' undeclared (first use in this function)00:28
bryce../../src/i830_dri.c:1162: error: (Each undeclared identifier is reported only once00:28
bryce../../src/i830_dri.c:1162: error: for each function it appears in.)00:28
bryce../../src/i830_dri.c:1162: error: expected ';' before 'flip'00:28
bryce../../src/i830_dri.c:1168: error: 'flip' undeclared (first use in this function)00:28
brycethat's with xserver-xorg-video-intel_2.5.1-1ubuntu7.dsc that's already in the archive.  I wonder if libdrm or something has changed?00:29
brycemm bug #308387 perhaps00:40
ubottuLaunchpad bug 308387 in linux "[Jaunty] trying to overwrite `/usr/include/drm/drm_sarea.h', which is also in package libdrm-dev" [Undecided,Fix committed] https://launchpad.net/bugs/30838700:40
tjaaltonbryce: we discussed it with jbarnes on #ubuntu-desktop05:58
tjaaltonthe kernel drm headers need updates05:58
tjaaltoneither that or we Replace linux-libc-dev again and ship the intel headers in libdrm-dev06:01
* jcristau is happy he misses out on that fun for now06:57
looljcristau: :)09:29
looltjaalton: Did they push the updates to the upstream kernel?09:30
tjaaltonlool: no idea.. there are so many branches to choose from09:45
looltjaalton: Eh :)09:45
seb128tseliot: hi09:45
seb128tseliot: could you look at bug #316887? I'm wondering if the error comes from your tool to change the xorg config or from the capplet09:46
ubottuLaunchpad bug 316887 in gnome-control-center "gnome-display-properties: "Mirror screens" problems" [Undecided,New] https://launchpad.net/bugs/31688709:46
* tseliot has a look at the bug report09:46
tjaaltonlool: and it's not clear if that's even pushed to the kernel yet09:48
tseliotseb128: I've never seen that error before. I'll see if I can reproduce it here09:48
tseliotseb128: I doubt it depends on my changes though09:49
tseliotseb128: it looks like the author of the randr capplet rewrote more or less what I had done in my patch in gnome-rr-config.c10:49
pcjc2hi guys10:49
tseliotseb128: hehe, less work for me10:49
pcjc2that last comment sounds like something related to what I'm about to ask10:49
pcjc2does anyone else see / has seen reported, a nasty intereaction between gnome-settings-daemon 's Xrandr support, and output probing in the latest Intel video driver?10:50
pcjc2I'm getting a loop of events10:50
pcjc2Xrandr notify event -> pokes gnome-settings-daemon.10:50
pcjc2gnome-settings-daemon requests info on the screens from Xorg10:50
pcjc2Intel driver re-probes hardware (l a a a a a a a g g g g)10:51
pcjc2Somewhere along the line.. another notify event is emitted, and we get a lovely loop10:51
tseliotpcjc2: what happens exactly? What are the symptoms?10:51
pcjc2Nasty nasty lagging system, because the intel driver is re-probing its outputs as fast as the loop progresses10:51
pcjc2I also get a reprobe for every step-change in backlight brightness - although I don't actually seem to get an infinite loop on that one10:52
pcjc2My loop is usually triggered by pulling the AC adaptor out / putting it back in, which seems to fire off a LID event10:52
tseliotcan you reproduce the problem with backlight without the gnome-settings-daemon?10:53
tseliote.g. if you kill the gnome-settings-daemon10:53
pcjc2works much better after killing g-s-d10:53
pcjc2although HP still suck for not implementing it as ACPI notifications10:53
pcjc2(Hotkey scancodes.. on a machine designed for Vista? That doesn't even meet Microsoft's low standards)10:54
pcjc2ah damn10:54
pcjc2turned mu brightness right down - seems ot have shut down the backlight, and it won't turn back on10:54
pcjc2ok xbacklight managed to fix it, but something busted whatever the usual mechanism is..10:56
pcjc2hotkeys don't work10:57
pcjc2 /proc/acpi/video/GFX0/*/brightness return unsupported - and they did work before10:57
tseliothmm... it looks like g-s-d listens for any event coming from the screen10:58
tseliotand you can control the backlight from randr10:58
pcjc2Judging by the lag and system responsiveness after calling xbacklight, that is causing a path which does more work than it ought to10:58
tseliotok, maybe it would be useful to limit the events the g-s-d should listen to10:59
pcjc2although I'm not getting the jittering mouse pointer usually indicative of the the intel driver probing its outputs10:59
pcjc2I backtraced them.. I can let you know what type of event I was getting10:59
pcjc2but it appeared to be the same Xrandr subtype for the brightness change, and the situation which got me into a big long loop10:59
pcjc2I sent the details to the Xorg ML, should I forward to ubuntu-x?11:00
tseliotI can check the X ML11:00
pcjc2basically, its event subtype 2 I'm getting11:00
pcjc2Subject: Xrandr loop with gnome-settings-daemon  [WAS: Re: Intel GM45: Loop of continuously triggered output detections11:01
tseliotok, I found it11:01
pcjc2tseliot: Is your patched gnome-rr-config.c in Jaunty?11:06
pcjc2(Was wondering if a kindof race could be happening between that and g-s-d's code11:06
tseliotpcjc2: yes, but I'm about to rework it.11:07
tseliotit only affects when you first load g-s-d from the xml and when you apply your settings from the applet11:08
pcjc2fair enough.. do you think the interaction between the two might have been the problem?11:08
pcjc2When I restart g-s-d, I sometimes get an assertion failure in gnome-rr11:08
pcjc2** (gnome-settings-daemon:20549): CRITICAL **: gnome_rr_config_save_to_file: assertion `error == NULL || *error == NULL' failed11:09
tseliotI can't reproduce the problem here and I don't touch events at all but you can try the new patch when it's available11:09
tseliotthat part is going away11:09
pcjc2no - I'm suspecting this is something the Intel driver might be exacebating11:09
pcjc2I don't see why it needs to probe hardware on a call to request info11:10
tseliotit's a bit weird11:11
pcjc2XRRGetScreenSizeRange causes the probe11:11
pcjc2I guess somewhere along the lines, it needs to probe11:11
pcjc2OTOH, something really needs to cache if its going to want this info at every brightness change11:12
tseliotXRRGetScreenSizeRange is called every time an event from randr is caught by the g-s-d11:13
pcjc2you're telling me...11:13
tseliotwhich is not right11:13
pcjc2It did smack of "FIXME"11:14
tseliotI can write a patch to limit the number of events11:14
tseliotthe g-s-d listens to11:14
pcjc2but I thought it wise to prod the Xorg people to see if the loop was a problem11:14
tseliotyou did well11:14
pcjc2Perhaps we should disable retrival events whilst making a request like that - not sure what the correct locking semantics should be11:15
pcjc2New laptop, new drivers... new bugs11:15
tseliotif you change the backlight there's no need to check the size of the screen11:15
pcjc2the hardest part was figuring out it was g-s-d's "fault"11:15
tseliotand it shouldn't be difficult to change that11:15
pcjc2mostly by trauling through sysprof profiles to see which processes were actually executing code during the problem.11:16
pcjc2I've still not figured out what event it is which causes the infinite loop - brightness changes don't seem to be the problem11:16
tseliota lot of fun, eh?11:16
pcjc2(Although the request triggered by that is causing changing brightness to stall the whole system)11:16
pcjc2I already had most of the debug packages isntalled anyway.. I've been doing software development on a GPL Electronics CAD package, and have been testing out the new cairo rendering with the git HEAD intel drivers11:17
pcjc2poking sysprof to figure out where the bottlenecks are is kindof routine11:17
mvohey, just to confirm, we currently do not have nvidia drivers for the latest xserver-xorg-core? (not sure if that went though before I disconnected)11:18
mvoI add code in update-manager to deal with that for now11:19
mvosame for fglrx I suppose?11:20
tseliotmvo: if nvidia doesn't solve the problem we'll have to use X-Kit to enable the IgnoreABI option in xorg.conf for some drivers11:20
tseliotas some drivers work with that option in xorg.cofn11:20
pcjc2tseliot: looking at /usr/include/X11/extensions/randr.h shows the subtype of the notify events I'm getting back is RRNotify_OutputProperty11:21
mvotseliot: and that works reliable?11:21
tjaaltonmvo: basically unsupported11:21
tseliotmvo: which one? The option or X-Kit?11:21
mvotseliot: is this planed for alpha-3 ? or should I go ahead and enable checks for update-manager to warn the user and update the xorg.conf?11:22
mvotseliot: well, does xorg and nvidia play nicely together if that option is given even if the abi changed?11:22
tseliotmvo: not always11:22
tjaaltononly with 180 AIUI11:22
tseliotmvo: I believe it would be safe to disable nvidia in the xorg.conf for now11:23
mvothanks tseliot and tjaalton11:23
* mvo wonders if you irc need needs to start with "t" to be a great ubuntu xorg guy :P11:24
tseliotwe should change bryce into tbryce then :-P11:24
tseliotpcjc2: let me have a look at the protocol spec11:24
mvoyeah :)11:25
tjaaltonnice, 12kb diff between i915_drm.h from 2.6.28 and libdrm 2.4.311:26
tseliotpcjc2: ah, the g-s-d catches RRScreenChangeNotifyMask, RRCrtcChangeNotifyMask, RROutputPropertyNotifyMask11:27
tseliotpcjc2: it's definitely RROutputPropertyNotify's fault11:30
tseliot(for the backlight)11:30
tseliotwell, catching that is the cause11:31
tseliotnot the notification itself11:31
tseliotI'll patch that out11:32
mvois there a open bugreport about the abi thing in nvidia/fglrx? I would like to subscribe11:33
tseliotsure, let me check11:33
ubottuUbuntu bug 308410 in nvidia-graphics-drivers-180 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed]11:35
tseliotmvo: ^^11:36
mvothanks tseliot11:36
mvotseliot: I added a update-manager task (just so that if there is no update we can prepare)11:38
tseliotmvo: ok, good. This time we can use X-Kit as it supports commenting out things now11:39
pcjc2tseliot: Good stuff11:41
pcjc2I just scanned through the spec, and I don't think it mentions what Xrandr queries might cause the hardware to probe11:42
pcjc2but I did notice that if you haven't got the required timstamp (ie.. your idea of the configuration doesn't match the Xserver's), requests will fail11:42
pcjc2let me know if you want me to test anything before you push it out..11:43
pcjc2I'm pcjc2@cam.ac.uk, and am on the ubuntu-x ML11:43
tseliotpcjc2: ok, great. I'll send you an email as soon as my patches are ready11:50
tseliotpcjc2: if that request fails you should only get a RRCONFIGSTATUS which corresponds to the error. No additional probing should be involved11:55
pcjc2sure.. I just wondered if the reason they poked for details in the first place was so that they had a valid timestamp11:57
pcjc2Since they don't appear to have probed a full complement of details, I guess that doesn't really help11:57
pcjc2I've got to go now,11:58
pcjc2thanks for your assistance11:58
tjaaltonhum, intel fails after login13:00
tjaaltonexaCopyDirty: Pending damage region empty!13:06
tjaaltonhmm, maybe xserver-xorg-dev should depend on linux-libc-dev13:44
tjaaltonsince the drm headers have moved13:45
tjaaltonnot that it depends on libdrm-dev either, but..13:45
tjaaltonjcristau: do you agree with the above ^^ (once you get to enjoy the fun :)14:29
tjaaltonhuh, what's up with firefox.. "Couldn't load XPCOM"14:35
pcjc2tseliot: https://bugs.edge.launchpad.net/ubuntu/+source/libxrandr/+bug/307306 sounds like it might (possibly) be similar to the bug I was seeing14:38
ubottuUbuntu bug 307306 in xorg-server "upgrade to 2: makes session utterly slow" [Unknown,Confirmed]14:38
pcjc2although he's bisected it to a libxrandr2 upgrade14:38
pcjc2I tested again, and I'm actually still seeing some xrandr slowness with brightness changes, even with g-s-m killed. It _is_ better with it killed though14:39
tseliotok, so we're facing 2 different problems. One in the driver and one in g-s-d14:41
tseliotwhich should really be one problem14:41
tselioti.e. the one in the driver14:41
tseliotI can fix the one in g-s-d. Do you know what's causing the problem when g-s-d is not running?14:43
tseliotpcjc2: ^^14:43
pcjc2I've not traced it, sorry14:43
pcjc2I'm not at my house - otherwise I could GDB the X server from another machine14:44
pcjc2It would be telling to check if the reprobing on brightness changes are still coming from a client of the X server, not within it14:44
tseliotpcjc2: this would be a first step14:45
pcjc2Soren Saandman replied on Xorg saying that its the driver being bad for emitting events during the XRRGetScreenSizeRange request14:47
pcjc2When I'm at my other machine, I'll trace it. Right now, if I try to GDB X11, I'd have to do it from VT1, and then the video drivers wouldn't be running properly14:47
pcjc2I'd take the view, that since the spec. doesn't say when events are emitted, they can happen at any time14:48
pcjc2(Although I do think XRRGetScreenSizeRange ought not to probe unnecessarily)14:48
pcjc2KeithP would be the authority on this14:48
tseliotyep, this is why I said that it should really be one problem. What we can do is reduce the number of times XRRGetScreenSizeRange in g-s-d. This would be a workaround. KeithP or Jesse Barnes should be able to fix the real problem.14:51
pcjc2I'll see if they reply to the thread on -xorg, before proding them privately14:52
pcjc2I've worked with Jesse before fixing bugs in the driver, and have had conversations with Keith various cairo, intel graphics, and general electronics issues14:52
tseliotyes, they are both very helpful14:54
tseliotI met Jesse at the UDS in Mountain View and Keith was very helpful when I asked him some questions via email14:55
tjaaltonbryce: so what happened with NV?-)15:42
=== mvo_ is now known as mvo
brycetjaalton: ?16:59
superm1bryce, assuming he is meaning the conference call you sabdfl and them were on?17:00
bryceahh, thought something happened to -nv :-)17:01
bryceright, the meeting was very well attended, and went well, although we focused only on KMS17:02
tjaaltonno talk about the old drivers?17:03
brycethe main outcome of which is that nVidia will be bringing up their issues relating to KMS on the xorg dev list after they've had some time to digest and determine a plan of attack17:03
bryceI'm going to follow up on that by email17:03
tjaaltonthey'll fully release the vdpau-stuff on git.fd.o17:04
tjaaltonand aaronp asked keith if the video ABI is final for 1.6 (no reply though :)17:04
brycebtw, any issues on fglrx?17:09
brycenevermind; was just on the amd call, but it's ended now17:11
brycetold them we didn't know of any major new issues with fglrx; they know what kernel, etc. versions to target for 9.04 and I told them about kms for 9.1017:12
superm1bryce, well does fglrx work with current jaunty even?17:13
tjaaltonwell, fglrx doesn't work currently, thats pretty major so no idea what issues might be waiting to be discovered :)17:13
tjaaltonthe need for fglrx in 9.10 will be pretty low (I hope)17:14
bryceyeah I figured until they get us a new fglrx build the issues list is going to be short ;-)17:36
superm1are there more expected ABI bumps for the 9.10 dev cycle?  or does the X roadmap look out that far?17:37
bryceother than kms we generally don't look quite that far17:38
brycehowever I'd be surprised to not have to do an abi bump for 9.1017:38
superm1while we're stuck with these binary drivers situation, it'd be nice to have a release where they worked during development time :(17:39
bryceno kidding17:39
brycewell I'm hopeful that my early warnings about versions and so on has helped ati in accelerating when they'll supporting version out17:39
brycealso, isn't it about time for this month's fglrx release?  Or do they skip january?17:40
superm1yeah.  particularly it will be nice if these early KMS warnings play out properly in their roadmap17:40
superm1it's every month i thought, so probably very soon?17:40
brycethey had asked if we'd tested it yet... maybe they meant had we tested their testing version?17:41
tjaaltonwonder if nvidia will open the modesetting driver for the kernel..17:42
tseliotseb128: I have rebased my patch on the new gnome-desktop API. I don't know whether it solves the problem or not as I can't reproduce the problem described here: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/31440617:42
ubottuUbuntu bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed]17:42
tseliotoh, he's not here and I'm talking to myself17:42
bryceheh, heya tseliot17:43
tseliothey bryce17:43
tjaaltonthe abi versions haven't been changed on master, fwiw17:45
tjaaltonso it's possible that 1.7 will be abi-compatible with 1.617:46
tjaaltonbut I don't know if there are pending changes17:46
tseliotbryce: do you know where xfree() is defined in X?18:32
brycetseliot: libx11 would be my guess18:33
brycegrepping on 'xfree' turns up a few too many hits ;-)18:34
tjaaltonxserver-xorg-dev: /usr/include/xorg/os.h18:34
tseliotok, thanks18:36
NCommanderbryce, hola18:42
Alexia_Deathtseliot: did you try the patches?18:43
Alexia_Deathtseliot: once rc1 gets in repros you should nit need to patch anything on X side any more.18:43
=== mcasadevall is now known as NCommander
NCommanderbryce, I'm working on the issue we're having with Freescale SoC boards with Xorg -configure not working. I think the problem is that the autodetect rountines try and search the PCI and ISA buses, which won't find a framebuffer device on this board19:48
NCommanderIt seems the only reason we can get X working at all is because it defaults to /dev/fb0 if all else fails :-/19:49
bryceNCommander: heh19:49
bryceNCommander: ok first we typically don't use Xorg -configure to configure X, although no reason it shouldn't work, but that's the upstream approach for generating an xorg.conf file19:49
bryceyou may find it preferable to either use a custom xorg.conf you install directly, or else create a patched version of dexconf19:50
NCommanderI was asked to look at why it doesn't work, but if we don't use it ....19:50
NCommanderSO how does Xorg auto configuration work then?19:50
brycenow as to the autodetect routines, yes we can certainly fix those up19:50
brycethere's two things19:51
brycefirst is a PCIID-based approach for selecting drivers on a per-chipset basis19:51
NCommanderThat's not going to work here19:52
brycee.g. look in /usr/share/xserver-xorg/pci/19:52
bryceright, because the freescale stuff is not pci-based19:52
NCommanderso what's the second approach?19:52
brycethe second approach is a fallback system that selects a fallback driver based on architecture (or whatever)19:52
bryceso that's what falls back to vesa, fbdev, or whatever19:53
NCommanderWhich falls back to the fbdev device, which itself can't find the framebuffer, throws up its hands and tries /dev/fb019:53
NCommanderOk, so what's your official suggestion on how to fix this problem?19:54
bryceheh, you just asked me how it worked silly ;-)19:55
NCommandersince method one won't work, and method two isn't what I called desirable19:55
* NCommander falls over19:55
bryceI've no clue19:55
NCommanderhold on, I need to reboot19:55
brycewell you could maybe look into patching the fallback approach since it at least is not pci-based19:55
brycehowever I suspect that's going to be of limited good19:56
NCommanderWell, its loading the right driver, amazingly19:56
NCommanderBut yeah, thats a hack, even by my standards19:56
brycebeyond that, ehh19:56
NCommanderXorg -configure doesn't use the PCI based method, it calls the Probe method of each driver in-turn19:56
NCommanderWhich is why i got confused19:56
bryceyou probably need to develop something analogous to the PCI based method but that works more appropriately for however your hardware works19:57
NCommanderI'm going to guess the PCI code isn't something molder, and its just a stack of stuff in a function somewhere19:57
bryceyeah Xorg -configure is pretty old school and probably a blind alley for your purposes19:58
NCommanderUgh, i was afraid of that19:58
NCommanderHold on, I need to restart19:58
bryceif it is something you can hardcode into an xorg.conf, then patching dexconf would probably be a viable option... still semi hacky, but for this probably fine19:58
NCommanderbryce, sorry about that20:03
NCommanderbryce, what's dexconf specifically?20:55
bryceit's what's run during install to create the xorg.conf, or when doing a dpkg-reconfigure20:56
NCommanderOn both the LiveCD, and d-i, or just d-i?20:56
brycepretty sure both20:57
* NCommander is writing a report about this now20:57
=== federico1 is now known as fooderico
=== fooderico is now known as federico1

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!