On Fri, 2 Sep 2011 18:24:15 +0200 Leif Middelschulte <[email protected]> said:
just tested on an intel gma laptop with an hdmi cable plugged in... the conf dialog doesnt recognise the exdtra display or show it beint there. it doesn't name the existing display even it's just "output name". dragging the one preview thats there around is.. well.. buggy. it doesnt drag down and it wobbles around a lot. the preview area isn't even delimited in any way by a frame and the default dialog size makes the preview area useless (i have to resize the window to even SEE the screen preview object at all). the other frames dont fill their table regions and expand kind of oddly (they all scale as opposed to the resolution list having a fixed minimum width and not expanding for example). there's nothing there behavior-wise to detect screen plugins and show them or detect unplugs... i've tested and only thing that makes that work is the xrandr cmd-line - just run it to query randr and the display auto-adds the new screen (without your patch). no changes with it. :) anyway - just saying that this patch is a long way from being close to usable right now. :( > Hi, > > here we go again. This patch provides a randr dialog as a all-in-one > solution as raster requested. > This might render it kind of useless on devices with low resolution, > but anyway, I did it. > > What's there: > - global monitor connection policy adjustment (what shall happen, if > you connect a new monitor) > - rotation > - orientation > - enabling disabled monitors > - monitor arrangement > - listing in the modules dialog fixed > > What's not there: > - demodulization (direct integration into e) > - per output monitor connection policy > - save/restore > - output dependend window policies > - display monitor picture within dialog. (Icon already there, edje not > adjusted to use it yet) > > As I don't have access to a second monitor atm, I publish the state of > development, so people can see the progress and comment on its > functionality. I would be really interested whether the enabling of > formerly disabled monitors works. > > 2011/8/9 Carsten Haitzler <[email protected]>: > > On Mon, 8 Aug 2011 22:53:50 +0200 Leif Middelschulte > > <[email protected]> said: > > > >> 2011/8/8 Carsten Haitzler <[email protected]>: > >> > On Sun, 31 Jul 2011 02:59:21 +0200 Leif Middelschulte > >> > <[email protected]> said: > >> > > >> > review (yes i know the cover things you say don't work or aren't done yet > >> > etc.): > >> Thanks :-) > >> > > >> > 1. X-Enlightenment-ModuleType should be settings, not config (if u want > >> > this to be a separate module) in the module.desktop.in - this makes it > >> > show up. > >> No, will be demodulized. > >> > 2. as discussed - should be part of conf_display module > >> Will be done. > >> > 3. e_randr_screen_info in e_randr.c needs an EAPI if u want its symbol > >> > exported to modules! same in e_randr.h > >> Will add in future patch. > >> > 4. still missing an icon.png so people can build this. > >> No, it's there. I just have had a look at the moste recent patch I > >> sent. Maybe you applied the old version, which indeed misses it. > > > > hmm - seems i did look at the older patch. i didn't have the newer one > > marked. ) > > > >> > 5. segv on closing dialog. yay! crash here: > >> > > >> > (gdb) bt > >> > #0 0x00abc832 in ?? () from /lib/ld-linux.so.2 > >> > #1 0x0015ef01 in pause () at ../sysdeps/unix/syscall-template.S:82 > >> > #2 0x08071373 in e_alert_show (sig=11) at e_alert.c:43 > >> > #3 0x081120fb in e_sigseg_act (x=11, info=0xbfc10e1c, data=0xbfc10e9c) > >> > #at e_signals.c:125 4 <signal handler called> > >> > #5 _e_config_randr_dialog_subdialog_arrangement_smart_class_resize > >> > #(obj=0x876ca38, w=331, h=270) at e_int_config_randr_arrangement.c:182 > >> what the heck? Those lines are secured by checks for NULL. > > > > i don't think it was null - it was invalid somehow. > > > >> > 6. general design i think can be a lot better. this shouldn't be a > >> > separate config dialog to resolutions/rotation so, i'll put in some > >> > diagrams here. see attached. > >> Thanks for your effort here. > >> Well, I intended to seperate that resolution stuff away. Not > >> necessarily into another dialog, but into another page. Today's > >> monitors actually have and provide a prefered resolution. That > >> resolution is also used when screens are autoenabled on attachement > >> (policy). > >> My intention was that you usually don't deal with resolutions > >> nowadays. Why would you? Except you're trying to clone some other > >> output, which is another story. > > > > there lies the problem. there will be a lot of people who DONT have "todays > > monitors" still. nice old CRT's. a lot of people like to run e on "older" > > systems because it uses less resources. like it or not CRT's still are > > around and in use in enough numbers to need a resolution selector. > > > >> > notice how i have it all integrated. > >> Yeah, I split it intentionally to not overwhelm the user with options, > >> he/she/ doesn't even care about, just for the sakeness of all possible > >> options to be visible at once for advanced users with large monitors > >> and in need of those ;-) > > > > well in the case of a single screen it'll be the same as the current screen > > res dialog except you see a preview icon of the screen with its output name > > and 1 extra set of options: "never, always, ask". that's it. as its the > > only screen content is automatically "new screen" and u cant change it. the > > res is rotation, flip and resolution. it's better to be on the same area as > > then you can see how your options affect the preview (screens area) and the > > rest is done by dragging preview screens around and selecting them. > > configuring your screen imho is already an advanced option. imho the > > DEFAULT mode we should have in e for "all outputs without a specific > > config" is "always + new screen + no rotation/mirror + native res". then by > > DEFAULT it does what most people will want a they never have to poke in the > > screen config dialog. > > > >> But I think it would be nice to have the entire look customizable. But > >> I guess that'll be only feasable with elm. > >> > you can select the available screens and > >> > outputs in the main view - click on one and it shows its selected (eg the > >> > red box around the inner screen). > >> Already is there and themeable via edc. > >> > when you select a screen the surrounding option > >> > panes become "enabled" depending on options set and let you disable > >> > (never), enable, or set a screen to "ask" (ie when screen is detected e > >> > will pop up this dialog and select the new output found and thus ask u > >> > what to do with it every time). if set to "ask" all other panes > >> > (content, mirror/rot, resolution) are disabled. same if set to "never". > >> > if set to "always" this means the display is always enabled (if there is > >> > something plugged in - no point enabling it if there isn't). > >> As of now, the dialog provides more than just 'extend'. It let's you > >> chose a direction in which it extends the screen as well. > > > > the mock i drew does that too - drag the screens around. you can even then > > select how the extended screen ALIGNS to other screens. have you used the > > gnome or nvidia settings apps that let u configure screen layout? used the > > windows one? you just drag the screens around to lay them out. much simpler > > and nicer than a limited "list" of how to lay them out and select one. > > > >> > if always on choose the rotation and mirror flags (mirror flags > >> > are toggles, rotation is select one of the 4). choose if it clones the > >> > primary display (only thing i havent addressed here is choosing what the > >> > primary display is). and then select resolution. > >> I am not sure whether I get this right. How could we posibly select a > >> resolution of a monitor never connected? What if the new monitor does > >> not provide that resolution/mode? > > > > the dialog only shows connected monitors. if there is nothng > > connected/detected, then it doesnt show up there, so it cant be selected and > > configured. if the output is configured for native res and it doesnt provide > > one - probably just choose the highest one it provides, or if none, choose > > some default (640x480) etc. > > > > hmm - i forgot refresh rate selection there too i think. :) > > > >> > if selecting native - you basically > >> > mean "auto" - ie select the native res for the display (eg the lcd panel > >> > res) or whatever randr says is the "default" or "native" res. to choose > >> > which screen is to the left/right/above/below just drag them around the > >> > screens area. it should zoom in and our and move screens around as needed > >> > to fit what u are arranging. drag up and down to get screen to align to > >> > top-.middle/bottom of a larger screen (eg the vga one next to the hdmi > >> > one). > >> This is already there. But only those somehow connected to the most > >> upperleft screen are actually placed. This is due to rounding errors > >> when scaling down the representations and then up again for monitor > >> placement. > > > > i couldnt test with > 1 screen attached, so i only saw 1 dragable screen > > thing.. :) > > > >> > the screens in the screens > >> > area show the rotation icon (and hint with a base of the screen rotating > >> > too to indicate how the screen might be placed in real life) with some > >> > info in the screen giving rotation arrow, add a flip arrow for the flip > >> > modes and the output name, its configured state and resolution. > >> Screen rotation and reflection options are not there yet. > >> > > >> > that's what it should be imho. :) > >> > > >> >> Attached, > >> >> > >> >> a new set of patches. > >> >> > >> >> Basically their only intend is to cover the missing image issue. > >> >> There is no further difference. > >> >> So whether is conf_display integrated nor does it show up in e's > >> >> loadable modules list. > >> >> > >> >> Just the icon added, so testing is easier. > >> >> > >> >> For those who didn't follow: > >> >> 1.) Apply attached patches to root. Patches were created based on > >> >> revision 61924. > >> >> 2.) Compile and install e17. > >> >> 3.0) Open a terminal and > >> >> 3.1) Enter "enlightenment_remote -module-load conf_rand" and afterwards > >> >> 3.2) Enter "enlightenment_remote -module-enable conf_randr" > >> >> > >> >> You should now find a configuration dialog called "screen setup". > >> >> > >> >> Note that this is just testing. The module will be integrated into e > >> >> and replace by integrating the dialog e_int_config_display. > >> >> > >> >> If you face issues like a SEGV, please attach gdb and provide a > >> >> backtrace. I'll try to help asap. > >> >> > >> >> BR, > >> >> > >> >> Leif > >> >> > >> >> 2011/7/30 Leif Middelschulte <[email protected]>: > >> >> > 2011/7/30 Carsten Haitzler <[email protected]>: > >> >> >> On Sat, 30 Jul 2011 19:26:51 +0200 Leif Middelschulte > >> >> >> <[email protected]> said: > >> >> >> > >> >> >>> 2011/7/30 Carsten Haitzler <[email protected]>: > >> >> >>> > On Sat, 30 Jul 2011 17:11:20 +0200 Leif Middelschulte > >> >> >>> > <[email protected]> said: > >> >> >>> > > >> >> >>> >> 2011/7/30 Carsten Haitzler <[email protected]>: > >> >> >>> >> > On Fri, 29 Jul 2011 19:12:58 +0200 Leif Middelschulte > >> >> >>> >> > <[email protected]> said: > >> >> >>> >> > > >> >> >>> >> > why did you make it conf_randr. > >> >> >>> >> Because I thought maybe people don't need it all the time. Just > >> >> >>> >> to configure their setup once and afterwards they don't have to > >> >> >>> >> load it anymore. > >> >> >>> >> > already months ago i merged config modules - > >> >> >>> >> > it's part of conf_display - and e_int_config_display.[ch] in > >> >> >>> >> > there. as already mentioned missing icon.png, which we dont > >> >> >>> >> > have to worry about if you merge it in with conf_display. can > >> >> >>> >> > you do that? :) > >> >> >>> >> The reason I didn't merge in conf_display in the first place was, > >> >> >>> >> that people might not even have multiple displays, so the entire > >> >> >>> >> adjustment/policy stuff is useless to them (e.g. if their drivers > >> >> >>> >> just supports RandR <=1.1). > >> >> >>> > > >> >> >>> > this isn't just for multiple displays its for resolution too and > >> >> >>> > just fyi.. people with laptops need this quite often. :) if its > >> >> >>> > never used the code is never paged in from disk so it costs > >> >> >>> > nothing (if its already part of a module loaded anyway). > >> >> >>> > > >> >> >>> I know what conf_display did :-) I'll integrate its options into > >> >> >>> 'conf_randr'. > >> >> >>> > >> >> >>> >> But yes, I can merge in conf_display as another page in the > >> >> >>> >> toolbook. Though it'll have to wait a bit, until I'm finished > >> >> >>> >> with my next exam (end of next week). > >> >> >>> > > >> >> >>> > well it really should be one and the same dialog. to set up > >> >> >>> > resolution and rotation for each screen AND set up how many > >> >> >>> > screens are enabled or not and what the policy is when a new > >> >> >>> > screen is found (auto-enable, never enable, should it extend or > >> >> >>> > clone etc.). > >> >> >>> Per display stuff will be integrated along the integration of > >> >> >>> conf_display. Policy stuff is already there and "works for me"(TM). > >> >> >>> > > >> >> >>> >> I planned to adjust e_int_config_display so it works with CRTCs > >> >> >>> >> (RandR 1.2) instead of just the primary screen (RandR 1.1) as it > >> >> >>> >> does right now. I won't support RandR 1.1 in that dialog anymore. > >> >> >>> >> People whose drivers just support RandR 1.1 shall stay with the > >> >> >>> >> current dialog. So actually we need a new name like > >> >> >>> >> 'conf_display2' or rename current dialog to > >> >> >>> >> e_int_config_single_display and the new one > >> >> >>> >> e_int_config_multiple_displays > >> >> >>> > > >> >> >>> > it really should support the whole range - 1.1, 1.2 etc. - a user > >> >> >>> > shouldnt have to switch dialogs to choose what version of a spec > >> >> >>> > is supported. they have no clue which one is supported. they just > >> >> >>> > want it to "work". :) > >> >> >>> But randr <= and >1.1 work completly different. There is not code > >> >> >>> sharing. That's why I pliedge for leaving the dialog (conf_display) > >> >> >>> as is and just pop it up instead of integrating it into an else > >> >> >>> useless dialog (conf_randr), making the code more complicated than > >> >> >>> it needs to be. I went that way before and it's double effort > >> >> >>> without any advantage. > >> >> >>> As I proposed above: > >> >> >>> if (randr < 1.2) > >> >> >>> return conf_display; > >> >> >>> else > >> >> >>> return conf_randr; //with conf_display2 integrated > >> >> >>> > >> >> >>> If you can point out a good reason why to rewrite most of the old > >> >> >>> craft, I'll do it. But else I see more benefit in getting other > >> >> >>> things done. > >> >> >> > >> >> >> you are thinking like the programmer and not the USER. the USER > >> >> >> doesnt know ifd their driver does 1.1 or 1.2 and they shouldnt NEED > >> >> >> to know. it is the job of the app (e) to figure that out and present > >> >> >> the appropriate UI for their situation AND to use the appropriate > >> >> >> protocol. it is not the users job to try and figure out which > >> >> >> protocol they have and then go choose the right config dialog for > >> >> >> that protocol. it is the job of code in e to fgure that out and > >> >> >> switch internally as appropriate and presetn at the ui level the > >> >> >> features you can configure given that protocol version that our > >> >> >> driver happens to do that we DISCOVEr at runtime. > >> >> > Okay, > >> >> > I think we're arguing on different things. > >> >> > 1.) You're right about the dialog's behaviour. It should provide the > >> >> > user with a dialog resembling his driver's capabilities, no matter > >> >> > what they are. > >> >> > 2.) I tried to communicate: > >> >> > conf_display -> conf_display1 > >> >> > conf_randr -> conf_display //with integrated conf_display2 (for randr > >> >> >>=1.2) and conf_display1 > >> >> > > >> >> > conf_display will then be displaying either the current dialog (if ran > >> >> > on randr <1.2) or the new all-in-wonder dialog if supported. > >> >> > > >> >> > Is that okay? Man, sometimes seeing people for really simplifies > >> >> > discussions a big deal :-/ > >> >> > > >> >> > Thanks for your interest :-) > >> >> > > >> >> >> > >> >> >> -- > >> >> >> ------------- Codito, ergo sum - "I code, therefore I am" > >> >> >> -------------- The Rasterman (Carsten Haitzler) > >> >> >> [email protected] > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Leif > >> >> > > >> >> > >> >> -- > >> >> Leif > >> > > >> > > >> > -- > >> > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > >> > The Rasterman (Carsten Haitzler) [email protected] > >> > > >> > > >> > >> > >> > >> -- > >> Leif > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > > > > > > > -- > Leif -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
