#jogamp @ irc.freenode.net - 20130903 05:06:10 (UTC)


20130903 05:06:10 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20130902050610.html
20130903 05:06:10 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130903050610.html
20130903 07:58:18 * jk4 (~jk4@anon) Quit (Ping timeout: 264 seconds)
20130903 07:58:40 * jk4 (~jk4@anon) has joined #jogamp
20130903 09:33:29 <hrenovka> hm...it seems to be working
20130903 09:47:53 * xranby (~xranby@anon) has joined #jogamp
20130903 09:48:06 <xranby> hrenovka: great!
20130903 09:48:28 <sgothel> good morning all
20130903 09:48:43 <xranby> good morning
20130903 09:48:49 <sgothel> @Xerxes: thoughts about yesterday libav/ffmpeg deployment ?
20130903 09:50:26 <xranby> 20130902 11:36:12 <sgothel> in EU .. at least, we could distribute ffmpeg/libav ? I guess so ?
20130903 09:50:26 <xranby> 20130902 11:36:35 <sgothel> if so - we may simply offer a native jar file for folks who feel legally entitled :)
20130903 09:50:26 <xranby> 20130902 11:36:44 <sgothel> for windows and OSX .. I mean
20130903 09:50:26 <xranby> 20130902 11:37:42 <sgothel> we could drop this jar file .. and mention it's existence in a movie demo with such remarks
20130903 09:50:38 <sgothel> yup
20130903 09:52:26 <xranby> sounds like a new subtask for bug 686 https://jogamp.org/bugzilla/show_bug.cgi?id=686
20130903 09:53:59 <sgothel> so you agree that such approach is .. err .. OK ?
20130903 09:54:04 <xranby> we need to settle on the name for the media utils jar
20130903 09:54:24 <xranby> its OK. in the long run most of the media player will move from jogl -> this new jar
20130903 09:54:34 <xranby> IMHO
20130903 09:55:19 <sgothel> hu ? "in the long run most of the media player will move from jogl -> this new jar" ?
20130903 09:55:42 <sgothel> it would be just an injected libav/ffmpeg impl ..
20130903 09:56:01 <xranby> i expect all the gl media player code to move outside the jogl project into its own project
20130903 09:56:37 <sgothel> I see the GLMediaPlayer itself as a texture provider for encoded material, like JPEG ..
20130903 09:56:50 <sgothel> hence I like to keep it in .. not too much footprint
20130903 09:59:30 <sgothel> (yes .. JOAL dependency .. but we solved that one)
20130903 09:59:40 <sgothel> always a Q what is core .. and not ..
20130903 09:59:45 <xranby> my main point is to settle on a potential namespace now for media
20130903 09:59:51 <sgothel> i.e. a/v, jpeg, newt-input, .. etc
20130903 10:00:05 <xranby> and put the native libav jars into this new namespace
20130903 10:00:23 <sgothel> that doesn't matter
20130903 10:00:54 <sgothel> i.e. a native libav jar would simply load it's native libs .. before loading the GLMediaPlayer
20130903 10:01:10 <sgothel> a property can handle an 'init' callback, hence can be flexible
20130903 10:01:34 <sgothel> I mean, a property w/ a classname to load .. done
20130903 10:02:03 <sgothel> so the native libav jar will be self contained
20130903 10:02:04 <xranby> sgothel: in the future we may add a java only code media decoder etc
20130903 10:02:12 <sgothel> sure :)
20130903 10:02:26 <sgothel> then we surely need to enhance the factory model ..
20130903 10:02:48 <sgothel> Harvey mentioned something about an encoder he has available
20130903 10:03:12 <sgothel> we could use the NEWT approach for a GLMediaPlayer factory
20130903 10:03:26 <sgothel> for *the* GLMediaPlayer factory, which we already have
20130903 10:03:43 <sgothel> incl. AudioSink
20130903 10:04:03 <xranby> my thinking is that if we make people familiar with using a "jome" JogAmp media jar now we may extend this to include more decoders in the future without growing the jogl core
20130903 10:04:55 <sgothel> hmm .. in NEWT we have a similar situation right now, extend-able but offers reasonable defaults
20130903 10:05:28 <xranby> yes have the common api's in newt core and offer more pluggable jars for various input devices?
20130903 10:05:29 <sgothel> have to count the bytes .. for sure a good point to keep in mind
20130903 10:05:52 <sgothel> NEWT: I mean the whole impl. we have right now: x11, wgl, bcm ..
20130903 10:05:58 <sgothel> err win32 :)
20130903 10:06:09 <sgothel> you may remember .. you can add a property .. etc
20130903 10:06:48 <sgothel> NEWT extension := customJar + properyName of namespace (package-name)
20130903 10:07:14 <sgothel> so we can at least shape the FFMPEG/Android/etc impl. like this ..
20130903 10:07:28 <sgothel> plus earmark whether we shall push it in it's atomic JAR .. or not
20130903 10:08:27 <sgothel> sounds great .. yes, make it capable to have custom implementations easily ..
20130903 10:19:22 <sgothel> compromise to life with ? no response good response ? or am I discouraging you ?
20130903 10:33:17 <sgothel> Note: T-Shirts are out (Dominik, Mark and Jens)
20130903 10:43:58 <xranby> i got sidetracked with the jogamp forum
20130903 10:44:22 <xranby> http://forum.jogamp.org/Modern-JOGL-simple-texture-example-tp4029964p4029965.html
20130903 10:44:34 <xranby> (12:09:22) sgothel: sounds great .. yes, make it capable to have custom implementations easily .. <- lovely
20130903 10:45:05 <sgothel> you think pointing to FFMPEGGLPlayer would be too much ? :)
20130903 10:45:44 <xranby> that is probably ok
20130903 10:45:57 <xranby> especially if the jar contains FFMPEG* natives
20130903 10:46:11 <xranby> like you have made the choice to include this decoder
20130903 10:46:31 <xranby> i dont know about android
20130903 10:46:54 <xranby> in an ideal world everything work without too much fuzz and architectural jars
20130903 10:47:06 <sgothel> first would be the proper factory/namespace thingy like NEWT
20130903 10:47:49 <sgothel> then provide libav/ffmpeg native libraries for windows/OSX .. optional .. to be injected - nothing to do w/ our GLMediaPlayer impl.
20130903 10:47:52 <xranby> are all java modular systems broken and incompatible with each other?! :)
20130903 10:48:35 <xranby> (12:48:01) sgothel: first would be the proper factory/namespace thingy like NEWT <- ok good task
20130903 10:48:42 <xranby> (12:48:45) sgothel: then provide libav/ffmpeg native libraries for windows/OSX .. optional .. to be injected - nothing to do w/ our GLMediaPlayer impl. <-- ok
20130903 10:49:32 <sgothel> they will look good in the wiki roadmap now w/ features :)
20130903 10:49:50 <sgothel> ok .. the jar separation of what we have .. we will see later
20130903 10:50:40 <sgothel> currently hacking printing / tiled rendering support ..
20130903 11:25:27 <xranby> sgothel: are you adding support for multi gpu driver multiscreen?
20130903 11:25:33 <xranby> like the USB screens?
20130903 11:25:53 <sgothel> scratch head ..
20130903 11:26:29 <sgothel> orthogonal to printing/tiled-rendering you mean ?
20130903 11:26:36 <xranby> ye
20130903 11:26:58 <sgothel> we could do that already .. if a driver allows it via gpu == device
20130903 11:27:18 <sgothel> i.e. a USB gpu/display per X11-device
20130903 11:28:11 <sgothel> if you like to explode one 'scene' to it .. well, it's tiled-rendering related .. again :)
20130903 11:29:08 <xranby> possibly allow networked shaders GPU's using GPU's on diff machine?!
20130903 11:29:14 <xranby> shared GPU's
20130903 11:29:49 <sgothel> thats what we can do already sure .. via X11/GLX
20130903 11:30:04 <sgothel> have one NEWT demo/unit-test there
20130903 11:30:40 <sgothel> will play w/ tiled rendering on it later .. nice toy-idea :)
20130903 11:31:27 <xranby> thank you for adding awesome support for all these interesing usecases
20130903 11:35:13 <sgothel> your USB GPU/Display devices have X11 driver w/ OpenGL ?
20130903 11:35:49 <sgothel> AFAIR .. w/ JPEG / bitmap support only right ?
20130903 11:36:52 <sgothel> so if you have an java bridge to it .. you could use the tiled renderer, w/ USB per tile, and push the raw bitmap of each tile ..
20130903 11:36:56 <xranby> bitmap only support, a linux framebuffer and a X11 driver
20130903 11:37:01 <sgothel> rendered offscreen
20130903 11:37:12 <sgothel> w/ the GPU
20130903 11:37:36 <xranby> yes there is a GPU in the box i attach the usb screen to
20130903 11:37:56 <sgothel> I mean the OpenGL GPU for offscreen tiled rendering
20130903 11:38:15 <sgothel> spreading the bitmaps (result of rendering) to your devices
20130903 11:38:52 <sgothel> hmm .. at least would need to hook up one bitblit native method ..
20130903 11:38:57 <xranby> intel GMA 3150
20130903 11:40:12 <sgothel> yup .. would be a special 'swapBuffer' method: offscreen -> USB copy
20130903 11:40:58 <sgothel> the 'tiled' flavor I mention above .. only required for the huge monitor wall :)
20130903 13:02:41 <dfj> USB display? I saw them in the spec, but I have no idea what they are... ('hi, I'm dfj', btw)
20130903 13:11:18 <xranby> dfj: hi, since some years back there have been USB monitors on the marked using displaylink chips
20130903 13:11:54 <xranby> http://www.displaylink.com/technology/plug-and-display.php
20130903 13:12:40 <xranby> powering usb -> vga/dvi adapters usb monitors, usb projectors and multisear usb docking stations
20130903 13:12:49 <xranby> multiseat
20130903 13:13:10 <dfj> do they use the HID protocol, or proprietary drivers?
20130903 13:13:23 <xranby> for a while it was unknown how these devices operated
20130903 13:13:43 <xranby> but it got eventually reverse engineered http://www.youtube.com/watch?v=Ci8HbCRRZvM Reverse-Engineering DisplayLink devices [26C3]
20130903 13:14:14 <xranby> so for linux there is now an opensource driver based on this reverse engineering effort
20130903 13:14:36 <xranby> http://libdlo.freedesktop.org/wiki/
20130903 13:14:49 <dfj> so - fancy drivers - presumably using some sort of compressed stream (guess first, then clicks)
20130903 13:16:37 <dfj> are the chips available? might be a fun project to add screens to random other USB devices... but - interesting, nonetheless.
20130903 13:19:24 <dfj> I've been lurking for a few days - was just happy to find you folks on freenode since I hang here. It's been years since I got the jogamp stuff building, so I'm still fiddling with my windows toolchain. :/
20130903 13:19:59 <xranby> dfj: happy you joined
20130903 13:20:16 <xranby> dfj: i happen to use these kind of chips at my work
20130903 13:20:29 <xranby> using off the shelf usb monitors
20130903 13:20:44 <dfj> ah... so they can be had... you don't need to grab the consumer devices.
20130903 13:22:14 <xranby> btw.. x11 driver http://git.plugable.com/webdav/xf-video-udlfb/
20130903 13:22:22 <dfj> I'm thinking something like tht would be very sweet as a tiny aux display for when you don't want to fire up / or mess with main displays - particularly when messing with full-screen graphics or VM situations.
20130903 13:23:00 <xranby> http://git.plugable.com/gitphp/
20130903 13:23:19 <dfj> (I'm actually a keyboard modder by hobby - coder for fudes/rent)
20130903 13:23:35 <xranby> that git tree contains the most up to date source
20130903 13:23:44 <xranby> keyboard modder :D
20130903 13:23:46 <dfj> so - spent too much time slowly going mad in the USB specs.
20130903 13:24:00 <xranby> dfj: have you looked into the NEWT input API?
20130903 13:24:15 <dfj> like 'I'm a writer, but I wait tables to eat. :)
20130903 13:24:48 <dfj> not much - have you folks been fiddling the keyboard stuff much?
20130903 13:25:17 <xranby> sgothel have added a lot of work items to get good support for future input devices
20130903 13:25:30 <dfj> I try to get devices to the point they will surface as sane things, accross multiple platforms.. within reason. (wow - USB hosts are buggy)
20130903 13:25:37 <xranby> https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.1.0#NEWT_Input_Devices
20130903 13:25:47 <dfj> now you have my attention.
20130903 13:27:03 <dfj> oh cool - will have proper access to canonical USB HID stuffs soon?\
20130903 13:27:39 <xranby> you mean driverless hid devices?
20130903 13:27:43 <dfj> yeah.
20130903 13:28:01 <dfj> once a driver is in place - who knows what will be surfaced...
20130903 13:28:47 <xranby> dfj: the current spec will possibly enumerate the hid devices
20130903 13:29:19 <xranby> https://jogamp.org/bugzilla/show_bug.cgi?id=812 - Add USB Topology / Graph to query device location etc
20130903 13:29:53 <xranby> jogamp is of course first interested in input devices
20130903 13:30:06 <xranby> that send events
20130903 13:30:12 * dfj likes input devices - way easier to do on the device side.
20130903 13:30:57 <dfj> we port a lot of old keyboards and such to usb via either protocol converters, or controller replacements, as needed.
20130903 13:30:58 <xranby> if you happen to have a lot of driverless hid input devices
20130903 13:31:18 <xranby> then i guess we need to have a way to open generic usb HID access to these devices
20130903 13:31:23 <xranby> and write a simple driver in java
20130903 13:31:28 <dfj> ^
20130903 13:31:31 <xranby> that parses the USB frames
20130903 13:31:53 <dfj> ok - slow down... have you skimmed the spec?
20130903 13:31:55 <xranby> quite easy to do if you know what the binary format is
20130903 13:32:39 <xranby> dfj: i have skimmed the spec and built this usb blood analyser http://www.zafena.se/English/SimpleSimon
20130903 13:32:45 <dfj> teh USB HID descriptors define the binary format for each device, typically this descriptor is held in permanenet memeory on devices,
20130903 13:32:57 <xranby> that happens to use USB HID for data transfer to linux hosts
20130903 13:33:10 <dfj> ah, ok - cool.
20130903 13:33:58 <xranby> yes i used a PIC MCU
20130903 13:34:19 <xranby> and it basically tells the host system that it is a HID device when enumerated of a unknown type
20130903 13:34:29 <dfj> so - parsing them descriptors and eating well formed reports... a bit of a parse and such, ought to be straightforward -
20130903 13:34:42 <dfj> except no one seems to get it quite right (or the same)
20130903 13:35:00 <xranby> yes the device say i will use 64bit reports
20130903 13:35:03 <xranby> etc
20130903 13:35:17 <xranby> and then its an arbitary protocol used
20130903 13:35:37 <xranby> i have seen some manifacturers using fixed bytes in the report
20130903 13:35:38 <dfj> howver - the initial portion seems to be quite stable - the crazy seems to be when Os's map the events into their own notion of events...
20130903 13:35:47 <xranby> or a streamed protocol
20130903 13:36:11 <xranby> dfj: sure.. linux almost match 1:1 the usb hid spec
20130903 13:36:36 <dfj> I was quite impressed with teh report descriptor language - would have been an aweseome thing if xml had never been. :)
20130903 13:37:07 <xranby> maybe :) i am still impressed by IFF
20130903 13:37:15 <dfj> <cough> HUD page 7, ordinal 111
20130903 13:37:27 <xranby> the interchangable file format from the 80's by electronic arts
20130903 13:37:56 <dfj> linux parses it correctly, then maps 3 different HUD ordinals to the same linux key event. :/
20130903 13:38:24 <dfj> heaven forbit your keyboard actually has more than one of those keys present.
20130903 13:38:25 <xranby> let me see if i have that binder around
20130903 13:39:05 <xranby> ok found it i think.. binder labeled USB spec
20130903 13:39:50 <dfj> https://github.com/torvalds/linux/commit/437f3b199c437e2a9ac01b9ab733c78e5fc7c720
20130903 13:40:03 <dfj> shows the issue.
20130903 13:42:08 <dfj> - that's the diff, two more 111s were added, however, there was already another present, makign a total of three. :/
20130903 13:43:03 <xranby> from jogamps perspective we want to map everything to the NEWT namespace
20130903 13:43:12 <dfj> but - similar issues on other platforms - heck, the PS3 even claimed to support USB HID... oops.
20130903 13:43:20 <xranby> in order to have devices behave the same across devices
20130903 13:44:19 <dfj> excellent - if you could refrain from mapping things down like that... :p
20130903 13:44:49 <dfj> many to one mappings with io .. sketchy.
20130903 13:45:07 <xranby> so for keyboard we maps everything to unicode as close as possible. .. makes keyboard input easy for the programmer
20130903 13:45:23 <dfj> ouch...
20130903 13:45:43 <xranby> dfj: i mean usb spec have esc on binary 0
20130903 13:45:57 <xranby> that is maybe not ok for program logic
20130903 13:46:15 <dfj> that mapping should exist - as long as more raw ids are available to distinguish between, say, numpad digits and top row digits.
20130903 13:47:05 <xranby> sure we have worked on this.. https://jogamp.org/bugzilla/show_bug.cgi?id=641
20130903 13:48:22 <dfj> on zero?
20130903 13:49:01 <dfj> hut page 7 puts 0 as reserved - or are you speaking of HID in general?
20130903 13:50:50 <dfj> ah - right.. so, unicode as teh replacement for the ascii side of traditional events, with some sorrt of keycode to fill in the other side.
20130903 13:52:19 <dfj> fiddly , since there are many text input devices with different mappings from keycode to text.
20130903 13:54:15 <dfj> so - USB HID devices have a single, common HUT code, old PS/2 devices another set of codes - the OS will remap things into its own normalized codes - the JVM remaps those to another normalized map - you are hoping to do the same...
20130903 13:55:49 <xranby> we replace what the JVM did
20130903 13:55:58 <xranby> since we query the OS API's directly
20130903 13:57:03 <dfj> the OS (and java) typically merge all keyboards and mice into a 'single' device (with bizarre state transitions) - is NEWT bringing the devices together or allowing access to multiple devices independently? This is tricky with keyboards, as the OS likes to 'own' them.
20130903 13:57:07 <xranby> its possible we can move closer to the devices when we add support for more input devices
20130903 13:57:29 <xranby> i for one welcome multiseat setups
20130903 13:57:37 <dfj> ^
20130903 13:57:43 <xranby> and for those to work we need to keep keyboard and mouse separate
20130903 13:57:59 <xranby> and multiple keyboards separate
20130903 13:58:03 <xranby> etc
20130903 13:58:11 <dfj> as it stands now, I need to release USB devices from teh OS before I can hand them out to other applications/VMs.
20130903 13:59:11 <xranby> yes that can be an issue on some os
20130903 14:00:13 <dfj> which is nice - becasue (ok, mostly as a joke), I have a weird report which I pass to a vm, letting me feel a hair less freaky about connecting to important computers from a vm running on a windows workstation.
20130903 14:00:42 <dfj> it would break simple keyloggers.
20130903 14:00:50 <xranby> :)
20130903 14:01:01 <dfj> but obviously, not anything aware of common vms.
20130903 14:01:12 <xranby> my experience on windows was that two applications was able to listen to one HID device simultanious
20130903 14:02:01 <dfj> yes - but - keyboards are bidirectional, at least - you can certainly sniff, and then feed to a parser...
20130903 14:03:18 <xranby> dfj: do you have a homepage for your keyboards?
20130903 14:03:41 <dfj> but - this would require that the sniffer have dedicated code to handle the i8041 crap, as well as both sides of the device parser, etc... doable, but - a rare situation which at least would be poorly qa'd.
20130903 14:03:59 <dfj> no - just a bunch of random pics...
20130903 14:04:15 <dfj> http://poet.kvack.org/keyboards/
20130903 14:04:24 <dfj> let me point out some amusing ones...
20130903 14:04:59 <dfj> http://poet.kvack.org/keyboards/cur_layout.jpg
20130903 14:05:23 <dfj> is what I type on normally, i.e. right now.
20130903 14:05:45 <dfj> which roughly has this layout in full http://poet.kvack.org/keyboards/steel_ctrl/top_keys.jpg
20130903 14:06:25 <xranby> F24 :D
20130903 14:06:42 <xranby> its really cool
20130903 14:06:52 <dfj> this is a current project: http://geekhack.org/index.php?action=dlattach;topic=38206.0;attach=14132;image
20130903 14:07:35 <dfj> so - that original IBM controller does not generate key release events - so cannot map correctly to a modern USB HID...
20130903 14:08:18 <xranby> its based on one of these? http://www.seasip.info/VintagePC/ibm_1397000.html
20130903 14:08:26 <dfj> one could fake it by sending artificial release states in between down events... but, it would suck for gaming since keys (except for a couple of the metas) cannot be held down.
20130903 14:08:59 <dfj> xranby: not far off (and J. elliot rocks :) )
20130903 14:09:24 <dfj> these ones http://www.seasip.info/VintagePC/ibm_6110344.html
20130903 14:09:57 <dfj> weigh almost twice as much as the M versions - the F is capacitive, and supports extremely robust nkro.
20130903 14:10:32 <dfj> same mode 3 protocol, however - and they work fine with a simple protocol converter, unlike that evil tiny thing.
20130903 14:12:18 <dfj> but scroll down to see what sort of fun one can expect - lots of scancodes to find homes for.
20130903 14:13:22 <dfj> and - in the early days, when we tried to get them to work on PCs, we would patch the driver to support them - which was simple clean and sane under linux (and we eventually got our patch accepted as a module option.)..
20130903 14:13:55 <dfj> but under windows holy special case hell.. the 8041 driver in windows was hell.
20130903 14:14:01 <dfj> just.. wow.
20130903 14:14:15 <xranby> binary patching is an art form
20130903 14:15:32 <dfj> oh - not here, thankfully - the keyboards driver in windows has been a 'sample' that came with the ddk, mostly to show folks how to chain Ps/2 controlled devices..
20130903 14:15:55 <dfj> so - just required fiddling with signatures and permissions to get it installed.
20130903 14:17:34 <dfj> the trouble was - hooking into it wasn't enough - and even patching it wan't enough - as the very early code in the kernel itself would check for certain PS/2 legacy events (unrelated to ctrl-alt-del!) and fail on them.. but not do anything interesting except trigger a low level error - i.e. the PC speaker, something that folks might not have heard beep in years. :)
20130903 14:17:35 <xranby> i think NEWT needs patching to support your keyboards i am afraid :)
20130903 14:18:29 <xranby> at least if you want to use your keyboard on the raspberry pi
20130903 14:18:36 <dfj> well - not likely yet - *my* keyboards are remapped to moderate subsets of the normal HUT events -
20130903 14:19:18 <xranby> if so.. then it may simply work
20130903 14:19:34 <dfj> other folks who write frimware for these beasts support closer to a direct mapping to the original keys, which often causes OS to see keys pressed that haven't been properly supported in 15 years...
20130903 14:20:28 <dfj> I have a mapping I use for dealing with direct-input games, which are even more crippled than those using 'normal' windows keyboard code, as DI supports less keys.
20130903 14:20:37 <xranby> i am a bit surprised that i did add mappings for F13 - F24 in the LinuxEventDeviceTracker
20130903 14:20:41 <dfj> (only up to f15? why? macs?)
20130903 14:21:04 <sgothel> @Xerxes: Your ES2 raw demo will still fail on some platforms as long you don't perform a 1:1 match of GLSL vi GLContext's getGLSLVersion() .. or manually (or using the max avail GLSL) .. just mentioning .. (merged your code)
20130903 14:21:32 <dfj> well - you should - the linux ps 2 code could send you one, without my help, and it was already supported by the JVM.
20130903 14:22:54 <xranby> sgothel: ok i will keep it in mind
20130903 14:22:59 <sgothel> GLContext.getGLSLVersionString() !
20130903 14:23:33 <dfj> as a gamer it would drive me nuts - I'm fine with a game refusing to acknowledge f13-24.. but when that game blocks input from software remappers, and pulls from teh OS directly - *then* prunes the list of keys to be less than what the OS or Dinput would have supported... grr (I'm talking to you blizz)
20130903 14:24:52 <xranby> blizz == blizzard entertainment?
20130903 14:27:14 <dfj> oh - since I'm here, I actually have a question - before I spend too much time digging through gluegen->jogl, is there a mapping of of OpenGl names and IDs to the versions and calls where they are legal?
20130903 14:27:26 <dfj> yeah - WoW, SC2, D3, etc..
20130903 14:27:46 <xranby> dfj: can you refine the question?
20130903 14:28:22 <dfj> the sort of thing one might use to construct typesafe enums or such to use as parameters to a gl wrapper.
20130903 14:28:22 <xranby> if you run a runtime version check we enumerate all profiles and extensions that is available on the device
20130903 14:28:57 <xranby> http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases#Runtime_Version_Check
20130903 14:28:59 <rmk0> dfj: unfortunately not... i've been doing exactly that for over a year now
20130903 14:29:03 <rmk0> and 'lo
20130903 14:29:14 <dfj> yes - this info is cearly defined in the specs... I was hoping you had something more akin to.. bah.
20130903 14:29:28 <rmk0> it's a lot of painful searches through the old specs
20130903 14:29:41 <rmk0> and their manual pages, which are often incorrect
20130903 14:30:06 <dfj> so - I don't actually want to do that - but - it is the same map that is needed to recover the IDs when decompiling/deobfuscating gl calls from class files.
20130903 14:30:25 <dfj> 'clearly' ok - I was generaous.
20130903 14:31:09 <dfj> ah - so you are hoping to get something like java enums overtop of the interfaces sooner or later?
20130903 14:31:41 <dfj> (I'm out of date - I've been 'afk' from jogl for about 3 years I think. :(
20130903 14:31:58 <dfj> glad to meet rmk. :)
20130903 14:32:34 <xranby> dfj: the biggest news is.. that we finally have a new major release 2.0.2 !
20130903 14:33:59 <dfj> yes - this is awesome! - but I havent gone over it yet.
20130903 14:34:14 <xranby> thats why we have added a lot of new ideas to extend the API to handle new input devices and use cases for the future 2.1
20130903 14:35:03 <xranby> https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.1.0
20130903 14:35:18 * dfj is excited about haswell - will be able to get lower power opencl running serverside.
20130903 14:36:03 <xranby> intel is doing a quite ok job to release opensource drivers
20130903 14:36:29 <xranby> hopefully we will have opensource opencl drivers for both mobile and server chips
20130903 14:37:27 <dfj> this will be a dream.
20130903 14:37:27 <xranby> http://cgit.freedesktop.org/beignet <- the intel opencl efforts lands here
20130903 14:37:34 <rmk0> dfj: http://waste.io7m.com/2013/09/03/io7m-jcanephora-0.9.17-documentation/d1.xhtml
20130903 14:37:43 <rmk0> has been an ongoing project of mine for the last year or so
20130903 14:37:52 <rmk0> i can't stand raw opengl... i need type safety!
20130903 14:38:06 <dfj> !
20130903 14:38:08 <dfj> hee..
20130903 14:38:39 <dfj> much critical infrastructure on the interwebs is still on old undocumented perl. :p
20130903 14:39:00 <rmk0> /o\
20130903 14:39:01 <dfj> I'd almost prefer it was in sourcless binaries.
20130903 14:39:16 <rmk0> at least that'd encourage people not to keep working on it
20130903 14:39:56 <dfj> patching binaries is...
20130903 14:39:59 <dfj> yeah.
20130903 14:40:13 <dfj> jsut because it is madness doesn't mean it doesn't happen.
20130903 14:40:20 <rmk0> hehe
20130903 14:41:11 <dfj> you've poked around in teh prop drivers from nvid/ati - they are cutting it pretty close in terms of legal optimizations when linking to user code, last I checked. :)
20130903 14:42:26 <dfj> in a past life I was working on profilers... and recursively, my role was to performance tune them.
20130903 14:42:58 <xranby> dfj: opensource profilers?
20130903 14:43:04 <dfj> so - applying lightweight instrumentation to a profiler's instrumentation....
20130903 14:43:11 <dfj> ah, no.
20130903 14:43:34 <dfj> the profilers also did not require source for their targets.
20130903 14:45:21 <dfj> which is just as well, wehn in app-server (java) land, where the code was all sorts of bizarre generated frameworks and cruft running on - the word bloated doesn't do justice - app-servers.
20130903 14:46:06 <rmk0> one day someone's going to actually need all of those tens of thousands of classes
20130903 14:47:45 <dfj> millions of lines of code... and then the apps... oh god - if you think the folks who write those monsters are daft, you haven't seen usercode lately - it makes random checkouts from github feel like a cool dip in a highland spring.
20130903 14:49:26 <dfj> those days I wanted to just have a window pop up with the problem code: 49% appserver 49% your code 2% useful work.
20130903 14:49:55 <sgothel> (04:27:14 PM) dfj: is there a mapping of of OpenGl names and IDs to the versions and calls where they are legal?
20130903 14:50:08 <sgothel> the API doc has such names, yes
20130903 14:50:40 <dfj> well - I know the mapping exists, platonically...
20130903 14:51:07 <sgothel> no .. we could create a class for this, actually have a static one ..
20130903 14:51:10 <dfj> I'll check your api doc in case it is simple enough for me to parse for me friends.
20130903 14:51:11 <sgothel> but don't deploy it ..
20130903 14:51:34 <sgothel> so we stay in our interfaces .. as a 1st verification ..
20130903 14:51:59 <dfj> I have friends working on mods for this game - minecraft (which uses the other gl wrapper :( )
20130903 14:52:04 <sgothel> .. sure ,.. if your GL version is 3.2 core .. you cannot use 3.3 core .. oh well
20130903 14:52:40 <sgothel> if you use an IDE .. mouse over .. and you see API doc, if you have the *-source.zip attached to the jar
20130903 14:53:06 <sgothel> all API entries have detailed GL_VERSION_* numbers for all functions
20130903 14:53:25 <sgothel> even a khronos/opengl API doc link .. sometimes it works :)
20130903 14:54:08 <dfj> they deploy a toolkit to help other modders, by removing obfuscation as much as possible - however, what were cleanly named constants in the original binary become a bunch of ICONST, BIPUSH, SIPUSH instructions by the time they get it. :/
20130903 14:55:26 <sgothel> BuildStaticGLInfo is the magic class .. which results we currently only use at compile time
20130903 14:55:36 <dfj> so - yah - finding out which constants are legal for methods from particular versoins of the API - in practice only a subset is needed in a given 6 months, but still.
20130903 14:56:03 <sgothel> .. if you like such fine grained thing at runtime
20130903 14:56:33 <dfj> cool - I'll take a look.. and check licences, and/or bug you folks for more explicit encouragement if it looks helpful.
20130903 14:58:10 <sgothel> problem w/ BuildStaticGLInfo resulting java class for runtime: it's huge :)
20130903 14:58:22 <dfj> performance is not a concern, it might only need to be regenerated/applied every few months... I'm not certaing.
20130903 14:58:40 <dfj> very very build-level step.
20130903 14:59:08 <sgothel> nice .. then have fun w/ it :) .. maybe share your results .. blog or something
20130903 14:59:28 <dfj> also - not really my problem, I just happen to be more bytecody than most of the folks on that project.
20130903 15:00:00 <xranby> dfj: if you make it work for modders we would love to read about it.
20130903 15:00:16 <dfj> and, trying to contribute something since I'm new to the scene ... kinda like here. :)
20130903 15:02:06 <dfj> fer sure - their stuff is properly licenced and creditted already, I'm happy about that - and the scene has o very friendly if odd, relationship with the underlying game and its devs.
20130903 15:04:15 <sgothel> .. we always need something to show for SIGGRAPH .. hmm .. should file the new bug report :)
20130903 15:04:46 <sgothel> this time I better give them a phone call for our BOF, so we do not fight w/ Khronos's schedule :)
20130903 15:05:21 <sgothel> Maybe Harvey can do the trick .. he may know some organizers in his hometown :)
20130903 15:11:13 <sgothel> http://www.theregister.co.uk/2013/09/03/microsofts_nokia_plan_whack_apple_and_google/ outch .. Nokia dead now .. quite fascinating, reducing it's value over a few years and then buying it :/
20130903 15:11:52 <sgothel> .. and all w/o OpenGL :)
20130903 15:12:20 <xranby> symbian and mego had opengl so that got ditched first
20130903 15:12:23 <xranby> meego
20130903 15:12:54 <xranby> windows phones future without opengl is indeed interesting
20130903 15:15:09 * xranby (~xranby@anon) Quit (Quit: Leaving.)
20130903 18:23:50 * hrenovka (hrenovka@anon) Quit (Ping timeout: 240 seconds)
20130903 18:24:18 * hrenovka (hrenovka@anon) has joined #jogamp
20130903 18:37:31 * hrenovka (hrenovka@anon) Quit ()
20130903 20:04:45 * rmk0 (~rmk0@anon) Quit (Quit: Lost terminal)
20130903 20:06:39 * rmk0 (~rmk0@anon) has joined #jogamp
20130903 20:06:39 * rmk0 (~rmk0@anon) Quit (Changing host)
20130903 20:06:39 * rmk0 (~rmk0@anon) has joined #jogamp
20130903 20:31:10 * void256 (~void@anon) has joined #jogamp
20130903 22:06:21 * void256 (~void@anon) Quit (Remote host closed the connection)
20130904 05:06:10 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20130904050610.html