[10:03] <unggnu> hi all
[10:04] <unggnu> I have read about the xorg-options-editor and wanted to ask if there will be a modeline generator shipped within?
[10:07] <unggnu> the best would be a combination with a driver importer like displaconfig-gtk I guess. Maybe this part could be reused.
[10:12] <unggnu> For faulty hardware of course. Would make things for the concerned much more easier I think. Btw. displayconfig-gtk seems to depend on Python too.
[10:24] <jcristau> what's wrong with cvt and gtf?
[10:25] <jcristau> other than 'omg a command-line tool'
[10:27] <tseliot> ﻿unggnu: we haven't planned to add a modeline generator since this tool won't be used to set the resolution
[10:33] <unggnu> I thought it will be an advanced button for screen resolution?
[10:34] <unggnu> jcristau: People love their Guis :)
[10:35] <unggnu> It is if the monitor sends wrong data and the user is stick with low resolutions or hugh fonts thish could be fixed through adding modelines. And a driver importer or easy setup (add size, hsync and vsync) would things much more easier.
[10:36] <jcristau> i think most people don't use 10-year old monitors so they don't need that anyway
[10:36] <jcristau> but hey
[10:41] <unggnu> jcristau: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/120619
[10:41] <unggnu> I don't know, but it doesn't seem so rare
[10:42] <unggnu> jcristau: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/191000
[10:43] <jcristau> unggnu: i suspect most of those have been resolved by now
[10:44] <unggnu> The second one 191000 can't be fixed without adding a modeline according to Upstream.
[10:44] <jcristau> plus they don't need a modeline, they need correct size detected
[10:44] <unggnu> I don't know, just though it would make things much more easier if someone has this problem. It is of course no must have
[10:45] <jcristau> sure
[10:46] <unggnu> Several people could fix their problem with displayconfig-gtk because of the modlines but as we know it could break easily X.
[10:46] <unggnu> +e
[10:46] <unggnu> Btw. isn't the display size saved in the modeline?
[10:47] <jcristau> urgh. 1600x1024 doesn't make any sense
[10:48] <tseliot> ﻿unggnu: I'll think about adding this feature (since I'm the developer of ﻿xorg-options-editor)
[10:48] <bryce__> heya
[10:55] <tseliot> ﻿bryce__: hi
[10:57] <unggnu__> re, sorry, had a connection problem :)
[10:57] <bryce_> unggnu: no I think we want to get away from users generating modelines on their own
[10:58] <unggnu__> It is just for the case where the correct resolutions aren't recognized. Hidden in the advanced tab or something like that
[10:58] <bryce_> if they know what they're doing enough to generate one, then they probably have the aptitude to do it via command line via one of the tools jcristau suggests
[11:00] <bryce_> to be honest I'd sort of prefer them to report these as bugs so we can get them fixed
[11:00] <jcristau> unggnu: afaict 191000 doesn't need a modeline, just the PreferredMode option?
[11:00] <unggnu__> Ok, but most people don't know how to do it and it doesn't look so great. I have always asked why Windows hasn't this resolution problems but I guess it is most likely because they use a monitor driver in most cases.
[11:00] <bryce_> unggnu, this sort of falls into the category of the MonitorsOnlineDatabase spec (which I'm skeptical we even need anymore, but would fit in with that)
[11:01] <bryce_> unggnu, right.  displayconfig-gtk had a tool for getting the modeline/resolution by parsing it out of the windows .inf files, which I think might be useful
[11:02] <bryce_> esp. if coupled with a mechanism for sending the data back up (maybe via apport?)
[11:02] <unggnu__> That was what I suggested except of the data backup.
[11:03] <bryce_> ah, I thought you meant a modeline generator
[11:03] <unggnu__> a generator with an import function :)
[11:03] <bryce_> in any case, I'd like to keep it separate from tseliot's option editor, to keep things simple.  
[11:03] <unggnu__> import is easier I guess but if there is no driver file add the data from the monitor handbook
[11:04] <unggnu__> Ok, I just though a GUI would be great. Displayconfig-gtk is to risky imho.
[11:05] <unggnu__> I mean no automatically modeline generator. If the resolution isn't recognized you could go to the advanced tab or something like that and generate/import one.
[11:06] <bryce_> anyway, I think monitor configuration issues are reducing in frequency a lot, and I don't plan on investing time in gui tools for monitor config myself (I'd rather focus those energies on fixing the problem at its root), however if someone else were to write something which was adequately simple (and easy to maintain), and had provisions for getting the data upstream, I'd be open
[11:06] <unggnu__> If someone come to the IRC channel my resolution is 800x600 or something like that you can lead him to the advanced function so he could try it. Btw. does the Vesa driver accept modelines?
[11:06] <unggnu__> bryce_ Ok, sure.
[11:06] <bryce_> I think I'd be more open to just an importer, than a generator/importer
[11:07] <unggnu__> I personally never installed a monitor driver but it is possible that nearly every vendor has some on their homepage.
[11:07]  * bryce_ nods
[11:09] <bryce_> there's web pages out there to generate modelines, if people really wish to avoid cmdline tools
[11:10] <unggnu__> Yeah, I tried it but it is not very easy imho.
[11:11] <bryce_> I'll admit, I've never run into a bug where a modeline I generated with those web tools solved it.  Like jcristau points out, it usually ended up needing some server or driver option be set, or else some monitor quirk added to the xserver
[11:11] <bryce_> so that's what made me think maybe just an options editor would be the best approach, and just have people file bugs so we can care for the rest.
[11:11] <unggnu__> If I need a modeline to test I normally search for it :)
[11:13] <bryce_> unggnu__: btw I just sat in on a presentation by the bug team about a new bug web report / graph thing they're working on:
[11:13] <bryce_> http://people.ubuntu.com/~ogasawara/pkg-stats/openoffice.org.html
[11:13] <bryce_> (that's a prototype)
[11:14] <unggnu__> looks great
[11:14] <unggnu__> But could make depressive ;)
[11:14] <bryce_> hehe
[11:15] <bryce_> btw, I don't know if you look at this one - https://bugs.launchpad.net/ubuntu/+upstreamreport
[11:15] <bryce_> the last couple days I've been working on getting all the valid triaged bugs reported upstream for xserver-xorg-video-intel
[11:15] <tseliot> bryce_: this is a list of the value types which xorg-options-editor should deal with (apart from '...'): http://pastebin.com/m3a979927
[11:16] <bryce_> tseliot: ok
[11:16] <tseliot> bryce_: is there anything we should ignore?
[11:16] <bryce_> tseliot: how do you mean?
[11:17] <bryce_> unggnu__: I've still got a few left to do, but two of the three columns are now green :-)
[11:17] <tseliot> bryce_: here's the full XML with the options: http://pastebin.com/m40690da0
[11:17] <unggnu__> No, didn't know this statistic page. Is there any Wiki/ link page for them?
[11:18] <tseliot> bryce_: I mean, are there any options which we should not make available in the program?
[11:18] <bryce_> unggnu__: I'd love to see the third column green (it must be hard to achieve, only gedit has it green), but it would be a great goal to work for with -intel
[11:19] <bryce_> unggnu__: not sure, maybe from the QA page?  I learned of it at UDS, it's sort of experimental so not well advertised.
[11:19] <bryce_> tseliot: hmm
[11:20] <unggnu__> I am thinking about moving Bug 233787 upstream. It seems most likely that it is a pipe/output/quirk problem. I am asking for Force Pipe a and if it doesn't work I am going to move it upstream.
[11:20] <bryce_> tseliot: if it were me, I'd be lazy and just let them be freeform string entry, and if the user puts in something invalid, then they can deal with the breakage.  But you might be more kind than me.  :-)
[11:21] <bryce_> unggnu__: excellent
[11:21] <bryce_> tseliot: let me look more at it a minute
[11:21] <tseliot> ﻿bryce_: ok
[11:23] <bryce_> tseliot: well, could we associate regexp's for each?
[11:24] <bryce_> so we could specify { validator => '^\d+ \d+ \d+$', } { validator => '\d+\s*-\s*\d+' }
[11:26] <tseliot> bryce_: ok, so that we can check the type of the components of each typed value?
[11:27] <tseliot> decimal, string, etc.
[11:27] <bryce_> yeah
[11:27] <tseliot> ﻿bryce_: how would we deal with time?
[11:27] <bryce_> that'd probably be a sufficient sanity check to catch typos
[11:28] <bryce_> what options need time?
[11:29] <bryce_> ah blanktime
[11:29] <tseliot> BlankTime, OffTime, SuspendTime, StandbyTime, etc
[11:29] <bryce_> ok those are probably all measured in seconds, so it'd just be '^\d+$'
[11:30] <tseliot> bryce_: seconds, minutes, etc. I can set the precision of floats in any case
[11:30] <bryce_> or maybe '^(?:\d+|\d+\.\d+)$' or some such to permit fractional seconds, if it is allowed
[11:31] <tseliot> bryce_: HandleSpecialKeys has a "when" type
[11:31] <tseliot> what do we do with it?
[11:31] <bryce_> oh looks like time is in minutes
[11:31] <bryce_> but the regexp's would be the same
[11:32] <bryce_> tseliot: that looks like it's an enum with three values possible
[11:32] <bryce_> so a regexp for that would be /^(?:Always|Never|WhenNeeded)$/i
[11:33] <tseliot> bryce_: ah, ok. So, when possible I should include the accepted values too. I might define these types in an XML file
[11:35] <bryce_> sure, if you'd like
[11:36] <bryce_> tseliot: I know python's regexp handling isn't as convenient as in perl, but if it were me, I'd do all the type specification and checking just using regexp's, and keep it simple
[11:37] <bryce_> so for boolean, it'd be /^(?:1|0|true|false|yes|no)$/i or whatever
[11:37] <tseliot> ﻿bryce_: ok, good idea
[11:47]  * pwnguin wishes we had something as popular as regex for more complicated languages
[11:47] <pwnguin> antlr seems close
[11:58] <unggnu__> tseliot: Do your program get the values and descriptions from the man page or do you enter them all in your program?
[11:59] <tseliot> ﻿unggnu__: it parser the man page
[11:59] <tseliot> parses
[11:59] <unggnu__> Ok, that is the best way to do I guess :)
[13:37] <bryce_> tjaalton, jcristau: cjwatson noticed that the SECURITY module isn't getting loaded on xserver 1.5 in intrepid.  Has there been changes with that?  
[13:38] <bryce_> looks like it's disabled in 1.5
[13:54] <bryce_> hmm, seems to be an selinux change
[13:58] <tseliot> ﻿bryce_: the program should deal with these sections: device, screen, monitor, serverflags. Shall we keep serverlayout out?
[14:00] <bryce_> I'd think so, unless the other sections won't work without it present
[14:01] <tseliot> ok