kyak changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben/atusb 802.15.4 wireless, anelok and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
Nik05 has quit [Remote host closed the connection]
Nik05 has joined #qi-hardware
<wpwrak> whitequark: hmm, with current master, i still get "OpenGL context creation failed"
<wpwrak> ... in both GW and TW
<whitequark> export GDK_DEBUG=OPENGL
<whitequark> (and yeah, that is a completely different bug now)
<wpwrak> (the DISPLAY is to be able to see where it stops, without having to interact with it first)
<whitequark> I haven't a slightest clue
<whitequark> export GDK_DEBUG=ALL ?
wildlander has joined #qi-hardware
<wpwrak> https://0bin.net/paste/UfjdPqDDCosWCuvw#AVaaY8j+X8Svk6Vst8cDLQIYT06n+TYjqk8424eddG7
<wpwrak> the only things that look fishy to me are those g_value_take_object: assertion 'G_IS_OBJECT (v_object)' failed
<whitequark> hmmm, I have an idea
<whitequark> wpwrak: lol
<whitequark> this is a GTK bug
<wpwrak> all this debug output looks as if it should be useful to figuring out why my redirected TW disappears, too. and easier to use than an event handler override ;-)
<wpwrak> now what version would that be ... guess > 3.20 :-(
<whitequark> wpwrak: you can work around that
<whitequark> well...
<wpwrak> bump some refcount, i guess ? with something like #if GTKMM_VERSION_MINOR < 20
<wpwrak> err, < 21 or < 22
<whitequark> try this patch https://hastebin.com/hiqivovudu.cpp
<whitequark> no, hm
<wpwrak> that removes one of the two (solvespace:12851): GLib-GObject-CRITICAL **: g_value_take_object: assertion 'G_IS_OBJECT (v_object)' failed
<wpwrak> opengl creation still fails (in both windows), though
<whitequark> mh
<whitequark> aggravating
<whitequark> this one
<wpwrak> makes opengl context creation work for GW, but with a quirk: the screen comes up with a white background, and only turns black when something happens
<wpwrak> also, TW still fails
<whitequark> yeah I didn't patch that
<wpwrak> "happens" = e.g., hover over axis or icon
<whitequark> wpwrak: this one? https://hastebin.com/afiqahekeb.cpp
<wpwrak> applying on top of the previous one ... compiling ...
<wpwrak> nope. still exactly like before.
<whitequark> hrm
<whitequark> wpwrak: https://hastebin.com/sumaxofogi.hs ?
erichvk has joined #qi-hardware
sandeepkr_ has quit [Ping timeout: 240 seconds]
<whitequark> wpwrak: wait what
<whitequark> did you seriously write lilo?!
<DocScrutinizer05> didn't you know?
<whitequark> nope, I only knew about pstree
<DocScrutinizer05> wiki Werner Almesberger ;-)
<whitequark> even initrd
<DocScrutinizer05> pstree
<DocScrutinizer05> aah you mentioned that
<DocScrutinizer05> msdos tools
<DocScrutinizer05> s/tools//
<qi-bot> DocScrutinizer05 meant: "msdos "
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer06 has joined #qi-hardware
DocScrutinizer06 is now known as DocScrutinizer05
<wpwrak> of those, initrd was probably the best. proper innovation, the stuff patents should be made of.
<whitequark> lol
<wpwrak> and it also solved a rather nasty situation that began to build up at that time: distributions needed more and more different boot floppies, to avoid driver X from irreparably (well, until reset) trashing registers hardware Y. the joy of ISA. we already had modules, but no way to control at boot time which to load.
<wpwrak> whitequark: applied sumaxofogi on top of voqacunuyo and afiqahekeb
<wpwrak> GW now comes up cleanly (i.e., black background). TW still fails to bring up opengl
<wpwrak> lemme see if this goes away if i pick up the latest changes from git ...
<wpwrak> btw, there are two build warnings (gcc 6.2.0): https://0bin.net/paste/35w4kJQqZ4S6zFHj#rKiSYlanF4IYFDLhpKBgo5F-g2Cf+9C5WWZS1w5vT1X
<whitequark> yeah
<wpwrak> seems that they added some python antidote ;-)
<wpwrak> master @ 5c34b3f6ef86b94b9360023ddb5c6a35f935ade6 + sumaxofogi: GW and TW come up, background is black. however ... GW doesn't show the dashed lines until ther is some "action". also, slvs prints 2 x "glGetError() == 0x501"
<whitequark> bleh
<whitequark> what does MESA_DEBUG LIBGL_DEBUG bring out?
<whitequark> wait nevermind I can reproduce that
<wpwrak> whee ! :)
<wpwrak> now all looks good: GW and TW come up, background color is right, update happens in time, no complaints on the console.
<wpwrak> line drawing is still as glacially slow as before. but i guess that's unrelated.
<whitequark> wait, really?
<whitequark> that... makes no sense
<wpwrak> did that ever stop computers from misbehaving ? :)
<whitequark> wpwrak: pushed that to master
<whitequark> wpwrak: can you do: cmake . -DOPENGL=1 and rebuild?
<whitequark> wpwrak: nevermind, that's not actually possible to do on GTK3.
* whitequark stares
<whitequark> wpwrak: are you *absolutely sure* your X server / graphics driver combo isn't totally fucked up?
<wpwrak> built master ... works (just with the slowness)
<whitequark> can you show me GDK_DEBUG=ALL output and drag something a bit
<whitequark> on my machine, dragging a line in solvespace eats about 25% of a core plus 10% for xorg
<whitequark> and it's incredibly snappy
<wpwrak> x server is generally a bit sluggish, because if memory is always runnings low and there's a background load of junk in browser tabs, but nothing that would explain lines being so slow
<whitequark> what does the fps counter say?
<whitequark> again on my machine with intel graphics it takes 1ms to draw a frame
<whitequark> even with DocScrutinizer05's 1200ppi mouse it would probably not have much difference coping with the load!
<wpwrak> whoa ! GDK_DEBUG=ALL -> https://0bin.net/paste/tTlNPpLxPQ3UFTIf#En1+HvbdKYB1WoYK1yX6z0+A6U2TN18xVFxfXK5gAa6
<whitequark> amazing
<whitequark> Gdk-Message: 0: layout_start=0.0 paint_start=18.7 frame_end=467.2 predicted=16.7
<whitequark> what the *hell*
<whitequark> >paint_start=18.7 frame_end=467.2
<wpwrak> fps pretty consistently around 59
<whitequark> so it says "59 1/s" ?
<wpwrak> yes
<wpwrak> actually, the timing has changed
<wpwrak> before, it was lagging. now, the line isn't updated at all until the mouse stops moving
<whitequark> ohh
<whitequark> *sob*
<wpwrak> while, say, highlighting an axis, still happens, even while the line is "stalled"
<whitequark> what about this https://hastebin.com/najelucosu.lua
<wpwrak> trying ...
<wpwrak> nope, still the same
<whitequark> well, it's not actually *slow*
<whitequark> what happens is it waits for vsync.
<whitequark> somewhere.
<whitequark> I have no idea why, to be honest
<wpwrak> yeah, i think before it was genuinely slow/laggy. but now, it's some update prevention
<whitequark> thatmight have been
<wpwrak> what's interesting is that highlighting of axes does not move a "stalled" line.
<whitequark> what do you mean?
<wpwrak> time for a video :)
<whitequark> ... hang on I think I know what miiiight be happening
<whitequark> and it's rather disturbing
<whitequark> can you do: ulimit -s 8192 then run solvespace until it (presumably) crashes?
<wpwrak> wait .. having a system problem ...
<wpwrak> soemthing is filling my disk :(
<whitequark> O_O
<wpwrak> "special", isn't it ? :)
<whitequark> also uhm
<whitequark> look at the fps counter
<whitequark> doesn't that say 1/2ms every time?
<wpwrak> ah yes, that has gotten faster. could be because i killed the background activities.
<whitequark> ok so it has nothing to do with vsync
<whitequark> or glFlush
<wpwrak> ulimit so far hasn't caused any trouble. been running it for a couple of minutes, moving the mouse around
<wpwrak> what's also fun is that, when moving the mouse slowly over the horizontal/vertical position, the H/V appears and follows the mouse, while the line remains frozen
<whitequark> that one I know of...
<wpwrak> i'll go for a nap. no new bugs or nagging about features for a while ;)
sb0 has quit [Quit: Leaving]
wildlander has quit [Quit: Saliendo]
sandeepkr_ has joined #qi-hardware
_whitelogger has joined #qi-hardware
dandon has joined #qi-hardware
<wpwrak> whitequark: joyful news: seems that the opengl fixes also solved the text window dying when opening issue. at least i couldn't reproduce it in a number of tests now. updated patch: http://downloads.qi-hardware.com/people/werner/slvs/display-textwnd.patch
<wpwrak> one thing i noticed is that it seems that the window gets mapped before receiving its position, i.e., it / its frame very briefly appears at a different position, then the window is drawn at the final position. not sure who does what in that sequence.
<whitequark> wpwrak: that's "normal"
<wpwrak> perfect then ;-)
<whitequark> it's slightly inelegant but really not worth fixing
<whitequark> maybe once I rewrite all of the platform code to be sane
<wpwrak> yeah, doesn't cause problems
<whitequark> patch looks better now
<whitequark> well, I'm not happy with how it's structured and formatted but at least the semantics makes sense
<whitequark> will apply in a few hours
<wpwrak> thanks !
sandeepkr__ has joined #qi-hardware
sandeepkr_ has quit [Read error: Connection reset by peer]
sandeepkr_ has joined #qi-hardware
sandeepkr__ has quit [Ping timeout: 260 seconds]
<DocScrutinizer05> ((very briefly appears at a different position)) dosn't cause problems as long as no stupid windows desktop re-arranges all icons on screen permanently, like it's done when you switch to a different display resolution
<DocScrutinizer05> ...on windoze
<DocScrutinizer05> same effect happens as well when windows reloads display driver, on NVidia updating the graca driver crap
<DocScrutinizer05> 0,3s black, then deskzop comes back re-arranged
<DocScrutinizer05> desktop*
pcercuei has joined #qi-hardware
<DocScrutinizer05> rather boring video of "interesting snowflakes" http://maemo.cloud-7.de/share-service/DSCF2275.MOV - what's *really* highly interesting is the shake stabilizer of that Fuji camera, conider I took that video one_handed and the original shaking was X and Y just as bad as in Z-rotation, but the stabilizer totally removed it, except the latter
erichvk has quit [Ping timeout: 240 seconds]
pcercuei has quit [Quit: brb]
pcercuei has joined #qi-hardware
<strawberyargon> DocScrutinizer05, yea its good. i wonder what it would be like with even less compression :) example: http://blog.planet5d.com/2015/10/magic-lantern-shows-power-of-canon/
<strawberyargon> i feel "yea its good" didnt do it justice, its most acceptable to the point i dont think about shakyness. so my focus then went to the next thing, which was compression
<DocScrutinizer05> well, 5D mk-II (or III) yeah, I wish I could at least remote trigger this Fuji XQ1, but then it's a completely different class than Canon 5D and alas no magic lantern or _anything_ available
<DocScrutinizer05> a 5D would be overkill for my purposes
<DocScrutinizer05> but something with at least 100mm (better 150), focus distance <40cm, magnif >= 1.0 would be much appreciated
<DocScrutinizer05> and I actually started looking for cameras that allow hacked firmware and have a decent versatile hacked firmware
<DocScrutinizer05> a used 5D-Mk1 with primary 100mm macro might match all my criteria
pcercuei has quit [Quit: leaving]
<DocScrutinizer05> then OTOH a DL24-500 (with magn=4) is a nice telescope too ;-) I just wonder if the macro properties it has are any good, also if it ever might see hacked firmware
<DocScrutinizer05> >> Magnification Up to 4 x (angle of view equivalent to that of approx. 2000 mm lens in 35 mm [135] format)<<
<DocScrutinizer05> >>Focus range: Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) <<
<DocScrutinizer05> not quite sure if the latter really means I could do decent macro shots of areas 10*10mm, with lens min 30cm from object
<DocScrutinizer05> if "telephoto position" actually means "effective 2000mm lens" then I guess a distance of 70cm is quite good still, for effective magnification
<DocScrutinizer05> but too much guessing from my side in all that
<wpwrak> canon powershot powershow sd880is aka ixus 870 is goes down to 20 mm and runs chdk. and you've already seen many pictures taken by it ;-)
<DocScrutinizer05> ooh, that 4 times magnification is digital, meh
<DocScrutinizer05> I don't want "to go down to..." - I need a certain minimum distance of 30cm from lens to object ;-)
<wpwrak> at 20 mm, your main problem is to get light to the object, because the lens tends to shadow it pretty well, especially if you don't have a lot of ambient light.
<wpwrak> that nikon has a nice exposure range. the sd880is only goes -3/+3 EV, which can sometimes be insufficient.
<DocScrutinizer05> with DL24-500 in tele mode, minimum distance is 70cm which is maybe a tiny bit clumsy since I need to stand up to reach the camera, but as long as it makes crisp pictures (actually video, via HDMI-out) of an area as 'large' as 10*10mm
<wpwrak> naw, for getting close, you want macro mode.
<wpwrak> tele may sound useful, but it isn't :)
<DocScrutinizer05> I have three requirements: format filling 10*10mm macros, video to large monitor, *minimum* 30cm distance object<->lens
<DocScrutinizer05> if the thing can serve "dual-use" as mice "telescope" too, I won't complain
<DocScrutinizer05> nice*
<wpwrak> 30 cm or mm ?
<DocScrutinizer05> 2000mm effective lens sounds like the latter is granted
<DocScrutinizer05> CENTImeter
<DocScrutinizer05> 300mm
<wpwrak> you want a 10x10 mm field from 30 cm ?
<DocScrutinizer05> yes
<wpwrak> i hope you're good at grinding your own lenses ;-)
<DocScrutinizer05> why?
<wpwrak> i doubt anything even remotely like this is commercially available
<DocScrutinizer05> err
<DocScrutinizer05> aiui a 150mm lens has object size == picture_on_sensor size when object has 150mm distance from sensor
<DocScrutinizer05> aka "magnicication = 1.0"
<DocScrutinizer05> if it could get focused to 15cm distance
<wpwrak> yes, that's the problem
<DocScrutinizer05> macro lenses of 100mm or 150mm start at 30cm
<DocScrutinizer05> but I don't need a 25mm sensor
<DocScrutinizer05> 35*
<DocScrutinizer05> generally a macro lens is defined as "magnification >=1" which is just a question of lens focal length / min focus distance
<DocScrutinizer05> of course a 20mm lens can do magnification=1 in a focus distance of 20mm
<DocScrutinizer05> s/object has 150mm distance from sensor/object has 150mm distance from LENS/
<DocScrutinizer05> focal length == focus distance
<wpwrak> hmm, there do indeed semm to be lenses of the type you want: http://www.the-digital-picture.com/Reviews/Sigma-150mm-f-2.8-EX-DG-HSM-Macro-Lens-Review.aspx
<DocScrutinizer05> of course there are, I skimmed through them today :-)
<wpwrak> ah :)
<DocScrutinizer05> note that I'm massively guessing all that stuff, started to learn about it just 3h ago
<wpwrak> heh, focal range = lens length :)
<wpwrak> err, no, wrong parameter
<wpwrak> focal distance is what you want. and that's 30-44 cm in the ones you picked
<DocScrutinizer05> the Tokina looks actually reasonably well spec'ed and priced for the purpose
<DocScrutinizer05> but then I stumbled over http://cameradecision.com/review/Nikon-DL24-500
<DocScrutinizer05> then (about same time) I started considering firmware hacks
<wpwrak> (dl24) that 10 mm focus range is probably at 24 mm. at tele, the ratio may not be so good. but i guess you'd have to try it. that's the sort of stuff you don't find in specs, and even reviewers don't do much testing of macro.
<wpwrak> for firmware hacks, i think canon (with chdk) still rules
<DocScrutinizer05> >>Focus range: Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) <<
<wpwrak> well, not too bad
<DocScrutinizer05> so yes, "wide angle position" is ,ost likely "24mm zoom"
<DocScrutinizer05> I'm however more interested in the other "option"
<DocScrutinizer05> [2017-01-14 Sat 21:00:25] <DocScrutinizer05> if "telephoto position" actually means "effective 2000mm lens" then I guess a distance of 70cm is quite good still, for effective magnification
<DocScrutinizer05> aiui "effective 2000mm lens" means a 35/4mm object would fill the sensor's diagonal?
<DocScrutinizer05> well, nope wait
<DocScrutinizer05> meh, that math
<DocScrutinizer05> let's start with 500mm lens, which means a single lens 500mm from sensor focuses parallel ("infinity") light to the sensor
<DocScrutinizer05> so if you can focus this lens to an object 500mm away, you get a magnification of 1.0, right? IOW an object size of the sensor will fill the picture
<DocScrutinizer05> now we're roughtly with my flawed math above: the cam does 4 times digital zoom, making the sensor smaller. and the focus distance isn't 500mm but 700mm
<DocScrutinizer05> sensor size 1" (I assume that's diagonal?), so when magnification is "area" (is it?) we have an effective 1/2" sensor with digital 4x zoom, so a 0.5" object should fill the sensor diagonal, which is just within my requirement specs
<DocScrutinizer05> but then lens length is usually standardized to 35mm 'sensor', not 1"
<DocScrutinizer05> puzzling shit, makes me dizzy
<DocScrutinizer05> on the bright side, it seems the DL24-500 is waiting to suffer some thorough tests in next Saturn market
<wpwrak> well, they usually specify the equivalent
<DocScrutinizer05> yep, that's what I meant
<DocScrutinizer05> so when I use a 'fake' 500mm lens length value, I'd also need to use a 'fake' 35mm sensor, right?
<DocScrutinizer05> not 1"
<DocScrutinizer05> so an object of 35mm size would fill the sensor diagonal of DL24-500 when placed 700mm from lens surface in tele macro mode
<DocScrutinizer05> unless we apply digital 4x zoom
<DocScrutinizer05> well, actually 700/500 * 35mm
<wpwrak> isn't it 700 from "film" (sensor) surface ?
<DocScrutinizer05> nope, I think that's from lens surface
<DocScrutinizer05> the focus distance
<DocScrutinizer05> http://www.europe-nikon.com/en_GB/product/digital-cameras/premium-compact/dl24-500-f-2-8-5-6#tech_specs >>[W]: Approx. 30 cm (1 ft) to infinity, [T]: Approx. 2.0 m (6 ft 7 in.) to infinity, Macro close-up mode: Approx. 1 cm (0.4 in.) to infinity (wide-angle position), or 70 cm (2 ft 4 in.) to infinity (telephoto position) (All distances measured from center of front surface of lens)<<
<DocScrutinizer05> so I guess it's possibly correct to assume an object of 35mm *7/5 size would fill the diagonale of the 20.8 million px DL24 sensor, when placed a 700mm in front of lens surface in tele macro mode
<DocScrutinizer05> zooming in digitally might still yield somewhat useful video (for work) at 10 times that, so a 3 to 4mm would fill the monitor diagonal
<DocScrutinizer05> et a ~600*400 resolution
<DocScrutinizer05> and 70cm is more than enough headroom for all tooling like soldering irons etc ;-)
<DocScrutinizer05> WOW, Saturn makes that DL24 a sent from Starship Enterprise: viewfinder 2359 Megapixel
<DocScrutinizer05> should suffice for proper holograms
<DocScrutinizer05> wtf? http://cameradecision.com/review/Canon-PowerShot-G1-X-Mark-II >>Pro: Electronic (Optional) Optional Viewfinder // Con: Electronic (Optional) No External Viewfinder Option << what now?
<DocScrutinizer05> a pity but canon seems doesn't cut it
planasb has joined #qi-hardware
planasb has joined #qi-hardware
planasb has quit [Changing host]
paul_boddie has joined #qi-hardware
<paul_boddie> I didn't think that any of the Nikon DL models were actually available yet.
paul_boddie has quit []