| markizano | oh that is so weird.... | 00:41 |
|---|---|---|
| markizano | an app -- once running, can only run in that $DISPLAY at a time. :head_exploding: | 00:41 |
| markizano | use case: I have CPU-Graphics (Intel) + GPU-Graphics (Nvidia) both configured in a X11 environment. I can only get these to work when either have their own $DIPSLAY value set (e.g. separate "screens" as X describes them) | 00:42 |
| markizano | an app, once running seems to have a binding to that "screen" or $DISPLAY as either :0.0 or :0.1 depending on which screen gets the display for the app. | 00:42 |
| markizano | but this can be bypassed if the app runs as a separate user. | 00:44 |
| markizano | (I know this isn't a Devuan thing, just real-time realizing this aloud...) | 00:44 |
| gnarface | markizano: expected behavior because those two vendors aren't using compatible multi-head protocols at the driver level. you'll have to turn to Xinerama (which is not hardware accelerated) | 01:37 |
| gnarface | though it actually might be only a problem for programs that are themselves requiring hardware acceleration, like dvd playback or 3d opengl contexts | 01:40 |
| gnarface | not sure about that, been a while since i've had to mess with it | 01:40 |
| gnarface | hmm, or maybe what i'm remembering is that even with Xinerama it still only works for programs that themselves don't require hardware acceleration | 01:50 |
| gnarface | yea, i think that's it | 01:50 |
| gnarface | Xinerama will work for normal stuff but if you try to put one half of the same dvd playback window on each card you'll run into weird problems | 01:51 |
| markizano | LoL, not reporting as bug as much as just fascinated with the realization of it. | 02:53 |
| markizano | xinerama, unfortunately, segfaults when I configure to use it :( | 02:53 |
| markizano | and I can't figure out what kills it just yet. | 02:53 |
| pablocastellanos | gnarface: Sorry, I lost your “ugly hack” https://paste.debian.net/1260049/ for defining XDG_RUNTIME_DIR on the ~/.profile. Can you share it again? | 05:27 |
| gnarface | pablocastellanos: yea no problem: https://paste.debian.net/1260742/ | 06:43 |
| gnarface | fyi someone mentioned after that there's a binary called "mktemp" that might be better suited for this than pwgen and cut, but i think my approach creates a longer name | 06:44 |
| gnarface | at least than the default, but mktemp may be more flexible than i originally suspected | 06:45 |
| gnarface | later i recalled that someone had originally brought this "mktemp" binary to my attention when i'd initially made this hack but i had some good excuse for not changing it, but it may have just amounted to laziness | 06:47 |
| rwp | gnarface, Reading the comment "hopefully only temporary"... Nothing is as permanent as a temporary solution. :-) | 07:21 |
| gnarface | rwp: true, though for the record it's not needed for 0.25.4-1 which is what's currently there (in ceres) | 07:24 |
| rwp | The pedantic in me compels me to say mktemp is definitely the better way to create a private directory. FTW! XDG_RUNTIME_DIR=$(mktemp -d) | 07:25 |
| gnarface | i think what might have happened was i tried to figure out how to pass a template string to get it to create a name with more bytes in it but it wasn't cooperating so i just gave up | 07:26 |
| rwp | However I must say that using pwgen is a clever way to generate such a large random space that it is virtually guaranteed to work anyway. | 07:26 |
| rwp | You can always specify a template old-school with as many X's as desired. mktemp /tmp/foo.XXXXXXXXXXXXXXXX | 07:28 |
| psionic | Recommendations for good Linux ultrabook made recently? | 14:25 |
| djph | psionic: frame.work ? | 14:49 |
| djph | ... https://frame.work/ ... ugh, i can't copypaste today :( | 14:50 |
| spine-o-saurus | im getting an error trying to install libsdl2-mixer-dev on daedalus, libsystemd0 is not compat? | 16:55 |
| spine-o-saurus | nevermind it was apt sources were wrong | 17:23 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!