From: Simon A. <sim...@gm...> - 2021-02-24 16:04:56
|
Alright, looks like I got it working. GL locking is now glstate-based in my local copy and timed locking of GLs is working. Is anybody interested in the changes, as simple as they may be? Has anybody been working towards a 2.1.6? Best regards, Simon On Tue, Feb 23, 2021 at 8:44 PM Simon Ahrens <sim...@gm...> wrote: > Oh... sorry, I think I see what you mean about the bus level... it's > missing all/most of the address specific references a la ".gastate[addr]". > Alright... I'll dig deeper in the next weeks :) > > On Tue, Feb 23, 2021 at 7:39 PM Guido Scholz <gui...@gm...> wrote: > >> Am 23.02.21 um 17:03 schrieb Simon Ahrens: >> >> Dear all, >> >> Hi Simon, >> >> Now I've stumbled upon an issue locking GLs that I hope you can help me >> with: Whenever I try to lock one GL, the server seems to lock all GL but >> without sending 100 INFO messages about it. Here is what's happening >> (locking from session ID 887): >> >> [...] >> >> The server is running srcpd 2.1.3. Can you explain this behaviour? It >> seems to be working as I'd expect for GA devices, by the way (lock one, the >> others remain unlocked). >> >> Locks are not heavily tested. I don't know if there is any SRCP client >> which supports this feature. >> >> Having just a quick glance at the source code I found regarding the GL >> devices locks are implemeted on bus level. I have no clue if this is >> intended or not, but I guess this is an error. >> >> Guido >> >> >> _______________________________________________ >> Srcpd-devel mailing list >> Src...@li... >> https://lists.sourceforge.net/lists/listinfo/srcpd-devel >> > |