| bryce | hmm | 00:28 |
|---|---|---|
| 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 once | 00: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 |
| bryce | that'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 |
| bryce | mm bug #308387 perhaps | 00:40 |
| ubottu | Launchpad 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/308387 | 00:40 |
| tjaalton | bryce: we discussed it with jbarnes on #ubuntu-desktop | 05:58 |
| tjaalton | the kernel drm headers need updates | 05:58 |
| tjaalton | either that or we Replace linux-libc-dev again and ship the intel headers in libdrm-dev | 06:01 |
| * jcristau is happy he misses out on that fun for now | 06:57 | |
| lool | jcristau: :) | 09:29 |
| lool | tjaalton: Did they push the updates to the upstream kernel? | 09:30 |
| tjaalton | lool: no idea.. there are so many branches to choose from | 09:45 |
| lool | tjaalton: Eh :) | 09:45 |
| seb128 | tseliot: hi | 09:45 |
| seb128 | tseliot: could you look at bug #316887? I'm wondering if the error comes from your tool to change the xorg config or from the capplet | 09:46 |
| ubottu | Launchpad bug 316887 in gnome-control-center "gnome-display-properties: "Mirror screens" problems" [Undecided,New] https://launchpad.net/bugs/316887 | 09:46 |
| * tseliot has a look at the bug report | 09:46 | |
| tjaalton | lool: and it's not clear if that's even pushed to the kernel yet | 09:48 |
| tseliot | seb128: I've never seen that error before. I'll see if I can reproduce it here | 09:48 |
| tseliot | seb128: I doubt it depends on my changes though | 09:49 |
| seb128 | ok | 09:50 |
| tseliot | seb128: it looks like the author of the randr capplet rewrote more or less what I had done in my patch in gnome-rr-config.c | 10:49 |
| pcjc2 | hi guys | 10:49 |
| tseliot | seb128: hehe, less work for me | 10:49 |
| seb128 | cool | 10:49 |
| pcjc2 | that last comment sounds like something related to what I'm about to ask | 10:49 |
| pcjc2 | does 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 |
| pcjc2 | I'm getting a loop of events | 10:50 |
| pcjc2 | Xrandr notify event -> pokes gnome-settings-daemon. | 10:50 |
| pcjc2 | gnome-settings-daemon requests info on the screens from Xorg | 10:50 |
| pcjc2 | Intel driver re-probes hardware (l a a a a a a a g g g g) | 10:51 |
| pcjc2 | Somewhere along the line.. another notify event is emitted, and we get a lovely loop | 10:51 |
| tseliot | pcjc2: what happens exactly? What are the symptoms? | 10:51 |
| pcjc2 | Nasty nasty lagging system, because the intel driver is re-probing its outputs as fast as the loop progresses | 10:51 |
| pcjc2 | I also get a reprobe for every step-change in backlight brightness - although I don't actually seem to get an infinite loop on that one | 10:52 |
| pcjc2 | My loop is usually triggered by pulling the AC adaptor out / putting it back in, which seems to fire off a LID event | 10:52 |
| tseliot | can you reproduce the problem with backlight without the gnome-settings-daemon? | 10:53 |
| tseliot | e.g. if you kill the gnome-settings-daemon | 10:53 |
| pcjc2 | works much better after killing g-s-d | 10:53 |
| pcjc2 | although HP still suck for not implementing it as ACPI notifications | 10:53 |
| pcjc2 | (Hotkey scancodes.. on a machine designed for Vista? That doesn't even meet Microsoft's low standards) | 10:54 |
| pcjc2 | ah damn | 10:54 |
| pcjc2 | turned mu brightness right down - seems ot have shut down the backlight, and it won't turn back on | 10:54 |
| pcjc2 | ok xbacklight managed to fix it, but something busted whatever the usual mechanism is.. | 10:56 |
| pcjc2 | hotkeys don't work | 10:57 |
| pcjc2 | /proc/acpi/video/GFX0/*/brightness return unsupported - and they did work before | 10:57 |
| tseliot | hmm... it looks like g-s-d listens for any event coming from the screen | 10:58 |
| tseliot | and you can control the backlight from randr | 10:58 |
| pcjc2 | Judging by the lag and system responsiveness after calling xbacklight, that is causing a path which does more work than it ought to | 10:58 |
| tseliot | ok, maybe it would be useful to limit the events the g-s-d should listen to | 10:59 |
| pcjc2 | although I'm not getting the jittering mouse pointer usually indicative of the the intel driver probing its outputs | 10:59 |
| pcjc2 | I backtraced them.. I can let you know what type of event I was getting | 10:59 |
| tseliot | good | 10:59 |
| pcjc2 | but it appeared to be the same Xrandr subtype for the brightness change, and the situation which got me into a big long loop | 10:59 |
| pcjc2 | I sent the details to the Xorg ML, should I forward to ubuntu-x? | 11:00 |
| tseliot | I can check the X ML | 11:00 |
| pcjc2 | basically, its event subtype 2 I'm getting | 11:00 |
| pcjc2 | Subject: Xrandr loop with gnome-settings-daemon [WAS: Re: Intel GM45: Loop of continuously triggered output detections | 11:01 |
| tseliot | ok, I found it | 11:01 |
| pcjc2 | tseliot: 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 code | 11:06 |
| pcjc2 | ) | 11:06 |
| tseliot | pcjc2: yes, but I'm about to rework it. | 11:07 |
| tseliot | it only affects when you first load g-s-d from the xml and when you apply your settings from the applet | 11:08 |
| pcjc2 | fair enough.. do you think the interaction between the two might have been the problem? | 11:08 |
| pcjc2 | ok | 11:08 |
| pcjc2 | When I restart g-s-d, I sometimes get an assertion failure in gnome-rr | 11:08 |
| pcjc2 | ** (gnome-settings-daemon:20549): CRITICAL **: gnome_rr_config_save_to_file: assertion `error == NULL || *error == NULL' failed | 11:09 |
| tseliot | I can't reproduce the problem here and I don't touch events at all but you can try the new patch when it's available | 11:09 |
| tseliot | that part is going away | 11:09 |
| pcjc2 | no - I'm suspecting this is something the Intel driver might be exacebating | 11:09 |
| tseliot | likely | 11:10 |
| pcjc2 | I don't see why it needs to probe hardware on a call to request info | 11:10 |
| tseliot | right | 11:11 |
| tseliot | it's a bit weird | 11:11 |
| pcjc2 | XRRGetScreenSizeRange causes the probe | 11:11 |
| pcjc2 | I guess somewhere along the lines, it needs to probe | 11:11 |
| pcjc2 | OTOH, something really needs to cache if its going to want this info at every brightness change | 11:12 |
| tseliot | XRRGetScreenSizeRange is called every time an event from randr is caught by the g-s-d | 11:13 |
| pcjc2 | you're telling me... | 11:13 |
| tseliot | which is not right | 11:13 |
| pcjc2 | It did smack of "FIXME" | 11:14 |
| tseliot | I can write a patch to limit the number of events | 11:14 |
| tseliot | the g-s-d listens to | 11:14 |
| pcjc2 | but I thought it wise to prod the Xorg people to see if the loop was a problem | 11:14 |
| tseliot | you did well | 11:14 |
| pcjc2 | Perhaps we should disable retrival events whilst making a request like that - not sure what the correct locking semantics should be | 11:15 |
| pcjc2 | New laptop, new drivers... new bugs | 11:15 |
| pcjc2 | Thanks... | 11:15 |
| tseliot | if you change the backlight there's no need to check the size of the screen | 11:15 |
| pcjc2 | the hardest part was figuring out it was g-s-d's "fault" | 11:15 |
| tseliot | and it shouldn't be difficult to change that | 11:15 |
| pcjc2 | mostly by trauling through sysprof profiles to see which processes were actually executing code during the problem. | 11:16 |
| pcjc2 | I've still not figured out what event it is which causes the infinite loop - brightness changes don't seem to be the problem | 11:16 |
| tseliot | a lot of fun, eh? | 11:16 |
| pcjc2 | (Although the request triggered by that is causing changing brightness to stall the whole system) | 11:16 |
| pcjc2 | I 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 drivers | 11:17 |
| pcjc2 | poking sysprof to figure out where the bottlenecks are is kindof routine | 11:17 |
| mvo | hey, 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 |
| tjaalton | no | 11:19 |
| tseliot | nope | 11:19 |
| mvo | thanks | 11:19 |
| mvo | I add code in update-manager to deal with that for now | 11:19 |
| mvo | same for fglrx I suppose? | 11:20 |
| tjaalton | yep | 11:20 |
| tseliot | mvo: if nvidia doesn't solve the problem we'll have to use X-Kit to enable the IgnoreABI option in xorg.conf for some drivers | 11:20 |
| tseliot | as some drivers work with that option in xorg.cofn | 11:20 |
| pcjc2 | tseliot: looking at /usr/include/X11/extensions/randr.h shows the subtype of the notify events I'm getting back is RRNotify_OutputProperty | 11:21 |
| mvo | tseliot: and that works reliable? | 11:21 |
| tjaalton | mvo: basically unsupported | 11:21 |
| tseliot | mvo: which one? The option or X-Kit? | 11:21 |
| mvo | tseliot: 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 |
| mvo | tseliot: well, does xorg and nvidia play nicely together if that option is given even if the abi changed? | 11:22 |
| tseliot | mvo: not always | 11:22 |
| tjaalton | only with 180 AIUI | 11:22 |
| tseliot | mvo: I believe it would be safe to disable nvidia in the xorg.conf for now | 11:23 |
| mvo | thanks tseliot and tjaalton | 11:23 |
| * mvo wonders if you irc need needs to start with "t" to be a great ubuntu xorg guy :P | 11:24 | |
| tseliot | we should change bryce into tbryce then :-P | 11:24 |
| tseliot | pcjc2: let me have a look at the protocol spec | 11:24 |
| mvo | yeah :) | 11:25 |
| tjaalton | heh | 11:26 |
| tjaalton | nice, 12kb diff between i915_drm.h from 2.6.28 and libdrm 2.4.3 | 11:26 |
| tseliot | pcjc2: ah, the g-s-d catches RRScreenChangeNotifyMask, RRCrtcChangeNotifyMask, RROutputPropertyNotifyMask | 11:27 |
| tseliot | pcjc2: it's definitely RROutputPropertyNotify's fault | 11:30 |
| tseliot | (for the backlight) | 11:30 |
| tseliot | well, catching that is the cause | 11:31 |
| tseliot | not the notification itself | 11:31 |
| tseliot | I'll patch that out | 11:32 |
| mvo | is there a open bugreport about the abi thing in nvidia/fglrx? I would like to subscribe | 11:33 |
| tseliot | sure, let me check | 11:33 |
| tseliot | https://bugs.launchpad.net/bugs/308410 | 11:35 |
| ubottu | Ubuntu bug 308410 in nvidia-graphics-drivers-180 "Latest Xorg removes nvidia driver ... conflicting xserver-xorg-video-4" [Medium,Confirmed] | 11:35 |
| tseliot | mvo: ^^ | 11:36 |
| mvo | thanks tseliot | 11:36 |
| mvo | tseliot: I added a update-manager task (just so that if there is no update we can prepare) | 11:38 |
| tseliot | mvo: ok, good. This time we can use X-Kit as it supports commenting out things now | 11:39 |
| mvo | excellent | 11:40 |
| pcjc2 | tseliot: Good stuff | 11:41 |
| pcjc2 | I just scanned through the spec, and I don't think it mentions what Xrandr queries might cause the hardware to probe | 11:42 |
| pcjc2 | but 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 fail | 11:42 |
| pcjc2 | let me know if you want me to test anything before you push it out.. | 11:43 |
| pcjc2 | I'm pcjc2@cam.ac.uk, and am on the ubuntu-x ML | 11:43 |
| tseliot | pcjc2: ok, great. I'll send you an email as soon as my patches are ready | 11:50 |
| tseliot | pcjc2: if that request fails you should only get a RRCONFIGSTATUS which corresponds to the error. No additional probing should be involved | 11:55 |
| pcjc2 | sure.. I just wondered if the reason they poked for details in the first place was so that they had a valid timestamp | 11:57 |
| pcjc2 | Since they don't appear to have probed a full complement of details, I guess that doesn't really help | 11:57 |
| pcjc2 | I've got to go now, | 11:58 |
| pcjc2 | thanks for your assistance | 11:58 |
| tjaalton | hum, intel 2.5.99.2 fails after login | 13:00 |
| tjaalton | exaCopyDirty: Pending damage region empty! | 13:06 |
| tjaalton | boom | 13:06 |
| tseliot | nice | 13:43 |
| tseliot | :-P | 13:43 |
| tjaalton | hmm, maybe xserver-xorg-dev should depend on linux-libc-dev | 13:44 |
| tjaalton | since the drm headers have moved | 13:45 |
| tjaalton | not that it depends on libdrm-dev either, but.. | 13:45 |
| tjaalton | jcristau: do you agree with the above ^^ (once you get to enjoy the fun :) | 14:29 |
| tjaalton | huh, what's up with firefox.. "Couldn't load XPCOM" | 14:35 |
| pcjc2 | tseliot: https://bugs.edge.launchpad.net/ubuntu/+source/libxrandr/+bug/307306 sounds like it might (possibly) be similar to the bug I was seeing | 14:38 |
| ubottu | Ubuntu bug 307306 in xorg-server "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [Unknown,Confirmed] | 14:38 |
| pcjc2 | although he's bisected it to a libxrandr2 upgrade | 14:38 |
| pcjc2 | I 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 though | 14:39 |
| tseliot | ok, so we're facing 2 different problems. One in the driver and one in g-s-d | 14:41 |
| tseliot | which should really be one problem | 14:41 |
| tseliot | i.e. the one in the driver | 14:41 |
| tseliot | hmm | 14:42 |
| tseliot | I 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 |
| tseliot | pcjc2: ^^ | 14:43 |
| pcjc2 | I've not traced it, sorry | 14:43 |
| pcjc2 | I'm not at my house - otherwise I could GDB the X server from another machine | 14:44 |
| pcjc2 | It would be telling to check if the reprobing on brightness changes are still coming from a client of the X server, not within it | 14:44 |
| tseliot | pcjc2: this would be a first step | 14:45 |
| pcjc2 | Soren Saandman replied on Xorg saying that its the driver being bad for emitting events during the XRRGetScreenSizeRange request | 14:47 |
| pcjc2 | When 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 properly | 14:47 |
| pcjc2 | I'd take the view, that since the spec. doesn't say when events are emitted, they can happen at any time | 14:48 |
| pcjc2 | (Although I do think XRRGetScreenSizeRange ought not to probe unnecessarily) | 14:48 |
| pcjc2 | KeithP would be the authority on this | 14:48 |
| tseliot | yep, 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 |
| pcjc2 | I'll see if they reply to the thread on -xorg, before proding them privately | 14:52 |
| pcjc2 | I've worked with Jesse before fixing bugs in the driver, and have had conversations with Keith various cairo, intel graphics, and general electronics issues | 14:52 |
| tseliot | yes, they are both very helpful | 14:54 |
| tseliot | I met Jesse at the UDS in Mountain View and Keith was very helpful when I asked him some questions via email | 14:55 |
| tjaalton | bryce: so what happened with NV?-) | 15:42 |
| === mvo_ is now known as mvo | ||
| bryce | tjaalton: ? | 16:59 |
| superm1 | bryce, assuming he is meaning the conference call you sabdfl and them were on? | 17:00 |
| bryce | ahh, thought something happened to -nv :-) | 17:01 |
| bryce | right, the meeting was very well attended, and went well, although we focused only on KMS | 17:02 |
| tjaalton | no talk about the old drivers? | 17:03 |
| bryce | the 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 attack | 17:03 |
| bryce | I'm going to follow up on that by email | 17:03 |
| tjaalton | ok | 17:03 |
| tjaalton | they'll fully release the vdpau-stuff on git.fd.o | 17:04 |
| tjaalton | and aaronp asked keith if the video ABI is final for 1.6 (no reply though :) | 17:04 |
| bryce | btw, any issues on fglrx? | 17:09 |
| tjaalton | issues? | 17:09 |
| bryce | nevermind; was just on the amd call, but it's ended now | 17:11 |
| bryce | told 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.10 | 17:12 |
| superm1 | bryce, well does fglrx work with current jaunty even? | 17:13 |
| tjaalton | well, fglrx doesn't work currently, thats pretty major so no idea what issues might be waiting to be discovered :) | 17:13 |
| tjaalton | the need for fglrx in 9.10 will be pretty low (I hope) | 17:14 |
| bryce | yep | 17:35 |
| bryce | yeah I figured until they get us a new fglrx build the issues list is going to be short ;-) | 17:36 |
| superm1 | are there more expected ABI bumps for the 9.10 dev cycle? or does the X roadmap look out that far? | 17:37 |
| bryce | other than kms we generally don't look quite that far | 17:38 |
| bryce | however I'd be surprised to not have to do an abi bump for 9.10 | 17:38 |
| superm1 | while we're stuck with these binary drivers situation, it'd be nice to have a release where they worked during development time :( | 17:39 |
| bryce | no kidding | 17:39 |
| bryce | well I'm hopeful that my early warnings about versions and so on has helped ati in accelerating when they'll supporting version out | 17:39 |
| bryce | also, isn't it about time for this month's fglrx release? Or do they skip january? | 17:40 |
| superm1 | yeah. particularly it will be nice if these early KMS warnings play out properly in their roadmap | 17:40 |
| superm1 | it's every month i thought, so probably very soon? | 17:40 |
| bryce | they had asked if we'd tested it yet... maybe they meant had we tested their testing version? | 17:41 |
| tjaalton | wonder if nvidia will open the modesetting driver for the kernel.. | 17:42 |
| tseliot | seb128: 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/314406 | 17:42 |
| ubottu | Ubuntu bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed] | 17:42 |
| tseliot | oh, he's not here and I'm talking to myself | 17:42 |
| bryce | heh, heya tseliot | 17:43 |
| tseliot | hey bryce | 17:43 |
| tjaalton | the abi versions haven't been changed on master, fwiw | 17:45 |
| tjaalton | so it's possible that 1.7 will be abi-compatible with 1.6 | 17:46 |
| tjaalton | but I don't know if there are pending changes | 17:46 |
| tseliot | bryce: do you know where xfree() is defined in X? | 18:32 |
| bryce | tseliot: libx11 would be my guess | 18:33 |
| bryce | grepping on 'xfree' turns up a few too many hits ;-) | 18:34 |
| tjaalton | xserver-xorg-dev: /usr/include/xorg/os.h | 18:34 |
| tjaalton | maybe.. | 18:34 |
| tseliot | ok, thanks | 18:36 |
| NCommander | bryce, hola | 18:42 |
| Alexia_Death | tseliot: did you try the patches? | 18:43 |
| Alexia_Death | tseliot: 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 | ||
| NCommander | bryce, 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 board | 19:48 |
| NCommander | It seems the only reason we can get X working at all is because it defaults to /dev/fb0 if all else fails :-/ | 19:49 |
| bryce | NCommander: heh | 19:49 |
| NCommander | Yeah | 19:49 |
| bryce | NCommander: 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 file | 19:49 |
| bryce | you may find it preferable to either use a custom xorg.conf you install directly, or else create a patched version of dexconf | 19:50 |
| NCommander | I was asked to look at why it doesn't work, but if we don't use it .... | 19:50 |
| NCommander | SO how does Xorg auto configuration work then? | 19:50 |
| bryce | now as to the autodetect routines, yes we can certainly fix those up | 19:50 |
| bryce | there's two things | 19:51 |
| bryce | first is a PCIID-based approach for selecting drivers on a per-chipset basis | 19:51 |
| NCommander | That's not going to work here | 19:52 |
| bryce | e.g. look in /usr/share/xserver-xorg/pci/ | 19:52 |
| bryce | right, because the freescale stuff is not pci-based | 19:52 |
| NCommander | so what's the second approach? | 19:52 |
| bryce | the second approach is a fallback system that selects a fallback driver based on architecture (or whatever) | 19:52 |
| bryce | so that's what falls back to vesa, fbdev, or whatever | 19:53 |
| NCommander | Which falls back to the fbdev device, which itself can't find the framebuffer, throws up its hands and tries /dev/fb0 | 19:53 |
| NCommander | Ok, so what's your official suggestion on how to fix this problem? | 19:54 |
| bryce | heh, you just asked me how it worked silly ;-) | 19:55 |
| NCommander | since method one won't work, and method two isn't what I called desirable | 19:55 |
| * NCommander falls over | 19:55 | |
| bryce | I've no clue | 19:55 |
| NCommander | hold on, I need to reboot | 19:55 |
| bryce | ummm | 19:55 |
| bryce | well you could maybe look into patching the fallback approach since it at least is not pci-based | 19:55 |
| bryce | however I suspect that's going to be of limited good | 19:56 |
| NCommander | Well, its loading the right driver, amazingly | 19:56 |
| NCommander | But yeah, thats a hack, even by my standards | 19:56 |
| bryce | beyond that, ehh | 19:56 |
| NCommander | Xorg -configure doesn't use the PCI based method, it calls the Probe method of each driver in-turn | 19:56 |
| NCommander | Which is why i got confused | 19:56 |
| bryce | you probably need to develop something analogous to the PCI based method but that works more appropriately for however your hardware works | 19:57 |
| NCommander | I'm going to guess the PCI code isn't something molder, and its just a stack of stuff in a function somewhere | 19:57 |
| bryce | yeah Xorg -configure is pretty old school and probably a blind alley for your purposes | 19:58 |
| NCommander | Ugh, i was afraid of that | 19:58 |
| NCommander | Hold on, I need to restart | 19:58 |
| bryce | if 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 fine | 19:58 |
| bryce | cya | 19:58 |
| NCommander | bryce, sorry about that | 20:03 |
| NCommander | bryce, what's dexconf specifically? | 20:55 |
| bryce | it's what's run during install to create the xorg.conf, or when doing a dpkg-reconfigure | 20:56 |
| NCommander | On both the LiveCD, and d-i, or just d-i? | 20:56 |
| bryce | pretty sure both | 20:57 |
| NCommander | Thanks | 20:57 |
| * NCommander is writing a report about this now | 20: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!