Re: [waffle] [PATCH 0/4] Remove link-time dependency of libwayland*
On 02/23/2015 12:32 PM, Emil Velikov wrote: > Hello list, > > Second to last part of removing all the window specific bits from > link-time to run-time (hail libdl). > > Note that the last patch looks a bit messy, mostly due to the wayland > design approach to have a handful of functions defined as static inlines > in the public header. > > This has been compiled tested only, as I don't have a wayland setup atm. > Will see if anyone volunteers over at #wayland (touch wood). I run Waffle's Wayland tests inside an X session. You can run Weston inside an X window. $ sudo yum install weston $ nohup weston & $ wflinfo -p wayland -a gles2 > > As usual the series can be found at my github repo in branch > wip/no-libwayland. > > Comments, suggestions even moderate bike-shed is welcome. wl_display_connect() crashes with SIGSEGV. I suspect the problem is a symbol collision: a wl_display_connect symbol exists in libwaffle and in the dlopened libwayland-client. But I'm not confident in that guess. This patch series is crazy stuff :) Before it's complete and working, we'll probably learn a few things about linker magic. Maybe I should be building libwaffle with -Bsymbolic? Hmm signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] gbm: Use EGLConfig to select the correct gbm format
By the way, I wrote a little Python script to ease the debugging
of GBM formats. You may find it useful too. Here's the example
usage:
$ gbm-format GBM_FORMAT_BGRA1010102
0x30334142
$ gbm-format 0x30334142
GBM_FORMAT_BGRA1010102
$ gbm-format B A 3 0
GBM_FORMAT_BGRA1010102
-8<- file: ~/bin/gbm-format
#!/usr/bin/env python3
import os
import os.path
import re
import sys
PROGNAME = os.path.basename(sys.argv[0])
def print_usage(file=None):
print('usage: ', file=file)
print(' {0} GBM_FORMAT_'.format(PROGNAME), file=file)
print(' {0} 0xabcd1234'.format(PROGNAME), file=file)
print(' {0} a b c d'.format(PROGNAME), file=file)
def usage_error():
print_usage(sys.stderr)
sys.exit(1)
def atoi(c):
assert(len(c) == 1)
return c.encode()[0]
def gbm_fourcc_code(a, b, c, d):
return (a) | (b << 8) | (c << 16) | (d << 24)
def gbm_iter_header():
regex = re.compile("#define\s+(GBM_FORMAT_\w+)\s+__gbm_fourcc_code\('(.)',
'(.)', '(.)', '(.)'\)")
with open('/usr/include/gbm.h') as f:
for line in f:
m = regex.match(line)
if m is None:
continue
test_name = m.group(1)
test_code = gbm_fourcc_code(*map(atoi, m.group(2, 3, 4, 5)))
yield test_name, test_code
def gbm_fourcc_code_to_name(code):
for hname, hcode in gbm_iter_header():
if hcode == code:
return hname
def gbm_fourcc_name_to_code(name):
for hname, hcode in gbm_iter_header():
if hname == name:
return hcode
def cmd_find_name(code):
name = gbm_fourcc_code_to_name(code)
if name is None:
die('failed to find name of fourcc code 0x{:x}'.format(code))
print(name)
def cmd_find_code(name):
code = gbm_fourcc_name_to_code(name)
if code is None:
die('failed to find fourcc code for {}'.format(name))
print('0x{:x}'.format(code))
def main():
if len(sys.argv) == 2:
if sys.argv[1].startswith('GBM_FORMAT_'):
name = sys.argv[1]
cmd_find_code(name)
elif sys.argv[1].startswith('0x') or sys.argv[1].startswith('0X'):
code = int(sys.argv[1], 16)
cmd_find_name(code)
else:
usage_error()
elif len(sys.argv) == 5:
code = gbm_fourcc_code(*map(atoi, sys.argv[1:5]))
cmd_find_name(code)
else:
usage_error()
if __name__ == '__main__':
main()
signature.asc
Description: OpenPGP digital signature
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] gbm: Use EGLConfig to select the correct gbm format
On 02/24/2015 10:43 AM, Tom Stellard wrote: > --- > > I think this is better than my original patch: > http://lists.freedesktop.org/archives/waffle/2015-February/001070.html > > However, piglit tests still fail because the alpha channel is always 1.0. > The gbm format being selected by eglGetConfigAttrib() is > GBM_FORMAT_XRGB, and I'm not sure if this is a bug in my patch > or something I need to fix in the EGL implementation. Thanks. Patch is merged to maint-1.4, maint-1.5, and master branches. It looks completely correct. Me and Daniel Stone diagnosed the Mesa bug. See 12:36 in the irc log. http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2015-02-26 signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [wflinfo] [RFC] platform-specific info from wflinfo
On 02/20/2015 01:49 PM, Jordan Justen wrote: > On 2015-02-20 12:58:07, Chad Versace wrote: >> On 02/17/2015 11:30 PM, Jordan Justen wrote: >> For the sake of apps who want to dump the info to a log file or to >> the console and get on >> with their lives, I think the default output format should be a >> single, giant string. But, as we're discovering in this conversation, >> a single giant string might not be appropriate as a one-size-fits-all format. >> I believe we can have it both ways, though, by adding some optional >> parameters >> to the API. >> >> void* >> waffle_display_get_info(struct waffle_display *dpy, >> enum waffle_display_info_format format, >> uint32_t flags); >> >> Then we have the ability to define API like this: >> >>// Returns a single, string suitable for log output. The return value >>// must be cast to `char*`. One valid flag is currently defined for this >>// format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT. >>waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0) >> >>// Returns Jordan array of strings. The return value must be cast to >> `char**`. >>// One valid flag is currently defined for this format, >>// WAFFLE_DISPLAY_INFO_VERBOSE_BIT. >>waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0); >> >>// Returns a JSON string. The return valud must be cast to `char*`. Two >>// flags are currently defined for this format: >> WAFFLE_DISPLAY_INFO_VERBOSE_BIT >>// and WAFFLE_DISPLAY_INFO_INDENT_BIT. >>waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0); >> >> Of course, the "simple" and "jordan" formats will be the first ones >> implemented. >> People can implement other formats in the future. (The JSON format, I'm just >> using that as a hypothetical example.) >> >> Do you think this is a good compromise between usability and extensibility? >> Does >> my proposal lack some important knob you think is needed? Or is my proposal >> just >> overall a bad idea? > > My idea was just to define a one-time API that left presentation of > the strings to the user of the library. Therefore, the Core API > wouldn't ever need to change past that point. It was also an attempt > to make it fairly easy to iterate through the results. > > One example of trouble we might get into could be > WAFFLE_DISPLAY_INFO_FORMAT_GLXINFO. Meaning we try to comma separate > and break lines. > > Except, we wouldn't know the best line length to use for breaking > lines. In that case it more likely the application could best format > it. (Assuming it was able to read the console text resolution.) > > But, I have to admit, your idea probably would be pretty helpful to > some applications. For example, JSON would probably be used by piglit. > > Assuming you don't think the string pointers output is too horribly > complex to document, then this seems like a good set to consider: > * WAFFLE_DISPLAY_INFO_FORMAT_STRING_POINTERS > * WAFFLE_DISPLAY_INFO_FORMAT_TEXT > * WAFFLE_DISPLAY_INFO_FORMAT_JSON > * WAFFLE_DISPLAY_INFO_FORMAT_XML > * WAFFLE_DISPLAY_INFO_FORMAT_CSV (Eh, I'm not sure I like this one.) > > The last 4 would be easy to implement based on the first. > > This set seems like enough where we could avoid the need to add any > more formats. That set looks good to me, except for CSV. I don't like CSV. The name STRING_POINTERS is clunky, but I can't think of a better alternative. For a first pass, I think we should implement STRING_POINTERS and TEXT. Then, soon after that, JSON. I consider XML a nice-to-have right now, just because I don't want to think about schema versioning. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
